esets_daemon freeze

[Boban 1]

I have had already this version, but didn't help. What was only changed, service started threads itself after kill.

[CircleSquare 0]

We do install esets.amd64.deb.bin Version: 4.5.9.0 but still get the problem after running service some hours (+10)

service freeze and can´t stop by

systemctl stop esets

Mail-Queue log wrote: 

delivery temporarily suspended: connect to 127.0.0.1[127.0.0.1]:2526: Connection refused

connect to 127.0.0.1[127.0.0.1]:2526: Connection refused

 

any other result out there?

 

Greetings

Edited November 6, 2017 by CircleSquare

[FHolzer 0]

so far - no.

All i got from ESET is and was -> it should be fixed in 4.5.9
so far i didnt had the error anymore.

all you can do is open an offical Support Ticket, collect your logs, send it to ESET, wait and hope.

Can you post your installed versions with 

cd /opt/eset/esets/sbin
./esets_update --verbose

and also daemon version with
 

/opt/eset/esets/sbin/esets_daemon --version

 

[CircleSquare 0]

tanks for reply, our update level:

./esets_update --verbose
Update is not necessary - the installed virus signature database is current.
ESETS Update utility
+-+--------------------+------------------------+------------------------+
| | Module             | Available version      | Installed version      |
+-+--------------------+------------------------+------------------------+
| | loader             |        1069 (20161122) |        1069 (20161122) |
| | perseus            |        1532 (20171031) |        1532 (20171031) |
| | engine             |       16363 (20171106) |       16363 (20171106) |
| | archiver           |        1269 (20170913) |        1269 (20170913) |
| | heuristic          |        1180 (20170914) |        1180 (20170914) |
| | cleaner            |        1150 (20171031) |        1150 (20171031) |
| | horus              |        6405 (20171106) |        6405 (20171106) |
| | dblite             |        1093 (20170725) |        1093 (20170725) |
+-+--------------------+------------------------+------------------------+

/opt/eset/esets/sbin/esets_daemon (esets) 4.5.9

sound like the new version works for you..

maybe we got an other fault while reinsert the daemon as mail filter

the freeze of service stand again this thoughts

 

Greetings

[lberes 0]

Hi chaps,

I updated to the latest version 4 days ago and today the daemon froze - this was the first time in the last 12 months.

It is quite interesting that while daemon says it is on version 4.5.9, on web interface it shows it is outdated.

Regards

Laszlo

[CircleSquare 0]

hi iberes,

 

it is only turned red while number is different up

the version 4.5.9 is the newest at this moment

 

Greetings

 

[FHolzer 0]

Just had this Error myself again. - so its not fixed with 4.5.9
it worked around 7days straight with no problem.

Im in contact with ESET Support again - will inform you guys about the progress.

Edited November 10, 2017 by FHolzer

[lberes 0]

4 minutes ago, FHolzer said:

Just had this Error myself again. - so its not fixed with 4.5.9
it worked around 7days straight with no problem.

Im in contact with ESET Support again - will inform you guys about the progress.

Thanks - what a shame.

[Data Two Limited 0]

HI All, the freezing still occurs on 4.5.9,

Issue is definately in the smtp module... I too lost many many hours tracking the causes and lost client patience as mails held in queue. I even rebuild a new postfix server, added esets and nothing custom on the server and still the SMTP randomly freezes. it does appear to be related to workload. Perhaps thread count in cfg needs to be higher but I have 3 SMTP MX weighted 10, 20, and 30 and the MX10 weight will freeze at random within 48hours, , the other two, hardly ever.

My fix is to create a restart script and using application "Monit" detect the smtp listing port for function, if not, execute restart script of esets service. works perfectly for me and saves man hours waiting for freezes and responding to it.

## Script Start ##

#!/bin/bash
/usr/bin/killall -9 esets_wwwi
/usr/bin/killall -9 esets_smtp
/usr/bin/killall -9 esets_daemon
/etc/init.d/esets start

## Script End ##

## Monit Start esets_av.cfg  (do your own homework here to setup monit) ##

check process esets with pidfile /var/run/esets_daemon.pid
start program = "/bin/bash -c '/etc/init.d/esets start'"
stop program = "/bin/bash -c  '/etc/init.d/esets stop'"
restart program = "/bin/bash -c  '/my_script_dir/service_esets_reset.sh'"

check host esets_scanner with address 127.0.0.1
if failed port 2526 protocol smtp within 2 cycles then restart

### Monit Start esets_av.cfg ##

 

Note, in the monit email relay setup, I used the master.cf smtp listening port where esets sends the data back to postfix for final delivery (eg mine is 12525) so even if the sets smtp inspection freezes, the smtp alerts from monit still get delivered as it skips the filter inspection in main.cf.

mail into postfix 25 > esets filter 2526 (localhost) > postfix 12525 (localhost) + various non looping -o ignore options > end user smtp/mailbox

 

 

 

Edited November 21, 2017 by Data Two Limited
spelling correct from autospelling esets to sets

[dmenl 2]

Just out of curiousity, are you guys using the ERA Agent on those machines as well?

[FHolzer 0]

sure

[dmenl 2]

Could you try (temporarily) stopping the "eraagent" service and see if that makes a difference? In my testlab it almost always freezes the esets_daemon when changing a lot of settings through ERA.

[FHolzer 0]

for me its a litte hard do reproduce the error.

Yes its still there - but it happens in a time span of Days to weeks.
not hours/minutes like for others.

but sure, i can try it.
 

Edited November 22, 2017 by FHolzer

[CircleSquare 0]

1 hour ago, dmenl said:

Just out of curiousity, are you guys using the ERA Agent on those machines as well?

we do stop ERA Agent services but the problem is still happen´s after some hours of processing mail.

16 hours ago, Data Two Limited said:

HI All, the freezing still occurs on 4.5.9,

Issue is definately in the smtp module... I too lost many many hours tracking the causes and lost client patience as mails held in queue. I even rebuild a new postfix server, added esets and nothing custom on the server and still the SMTP randomly freezes. it does appear to be related to workload. Perhaps thread count in cfg needs to be higher but I have 3 SMTP MX weighted 10, 20, and 30 and the MX10 weight will freeze at random within 48hours, , the other two, hardly ever.

My fix is to create a restart script and using application "Monit" detect the smtp listing port for function, if not, execute restart script of esets service. works perfectly for me and saves man hours waiting for freezes and responding to it.

## Script Start ##

#!/bin/bash
/usr/bin/killall -9 esets_wwwi
/usr/bin/killall -9 esets_smtp
/usr/bin/killall -9 esets_daemon
/etc/init.d/esets start

## Script End ##

## Monit Start esets_av.cfg  (do your own homework here to setup monit) ##

check process esets with pidfile /var/run/esets_daemon.pid
start program = "/bin/bash -c '/etc/init.d/esets start'"
stop program = "/bin/bash -c  '/etc/init.d/esets stop'"
restart program = "/bin/bash -c  '/my_script_dir/service_esets_reset.sh'"

check host esets_scanner with address 127.0.0.1
if failed port 2526 protocol smtp within 2 cycles then restart

### Monit Start esets_av.cfg ##

 

Note, in the monit email relay setup, I used the master.cf smtp listening port where esets sends the data back to postfix for final delivery (eg mine is 12525) so even if the sets smtp inspection freezes, the smtp alerts from monit still get delivered as it skips the filter inspection in main.cf.

mail into postfix 25 > esets filter 2526 (localhost) > postfix 12525 (localhost) + various non looping -o ignore options > end user smtp/mailbox

 

 

 

 

like u sad the  problem is part of the SMTP-Modul the daemon itself with no mail filter run for weeks with no problem..

got an strace64 log and an process dump with gdb from the frozen daemon to tech support two weeks ago.. still wait for an fix

at this point we do take out ESET Deamon for mail filtering to avoid problems in delivery

Edited November 22, 2017 by CircleSquare

[dmenl 2]

Well, what I've found out during my experiments is that you can use the "esets_smfi"  component with Postfix. Now, this is officialy a sendmail filter, but Postfix supports this filter with the "smtpd_milters" directive (hxxp://www.postfix.org/MILTER_README.html). The only downside is, the socket is created with root-only permissions so postfix cannot access it directly.

A workaround for this is using socat:

/usr/bin/socat -d -d TCP4-LISTEN:3537,range=127.0.0.1/8,fork UNIX-CONNECT:/var/run/esets_smfi.sock

And using this smtpd_milters option:

smtpd_milters = inet:127.0.0.1:3537

 

The benefits are that you don't have to specify another smtp server to relay to, and that you can accept and reject mail real-time based on the ESET Mail Security outcome (e.g. respond with a 500 code when malware is found). I've found this to work quite stable with Postfix, even though it's officialy a sendmail filter. Right now I'm just using it with socat as a system service:

[Unit]
Description=Socat tcp to eset socket
After=esets.service

[Service]
ExecStart=/usr/bin/socat -d -d TCP4-LISTEN:3537,range=127.0.0.1/8,fork UNIX-CONNECT:/var/run/esets_smfi.sock
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

 

[FHolzer 0]

thank you for the workaround,

Still - this isnt an open source or free product.
I payed for the smpt scan - i need a fix for it.

[dmenl 2]

Hmm, nevermind. The same thing happened to me just now when using esets_smfi. It really seems to be esets_daemon freezing for some reason.

[CircleSquare 0]

do you got anything new from tech support ?

[Michal Noga 0]

Yes, they support said, that is a esets_smtp daemon issue. They working on it.

[CircleSquare 0]

tanks four replay, do you got a time frame for the fix?

 

[Michal Noga 0]

I think, fix will be available soon. But I don't know exactly when. They engineers working on this fix. This is latest update message provided by ESET support guy from 27.november 2017.

[FHolzer 0]

My Last Response from ESET was on 22.11.2017 with the information:

Quote

wir haben noch keine neuen Informationen von unserer Entwicklung bekommen.
Sobald wir neue Informationen bekommen, melden wir uns wieder bei Ihnen.

which translates to "we have no glue yet but we will inform you if we find a solution"

[miro 0]

I am using ESET smtp scanner from 2 years and never had this problem before. Now with 4.5.9 it freezes and mails are deferred because of this error:

conversation with 127.0.0.1[127.0.0.1] timed out while receiving the initial server greeting

I tried service esets restart and it froze too. Had to kill all eset services and start esets.

Hope for a fix ASAP, it is inadmissible for a paid software in production version.

[miro 0]

Happened again 24 hours later

ESET support is useless, replied

Quote

On the ESET forums: https://forum.eset.com/topic/8166-esets_daemon-freeze. One customer there reported that work is being done on a fixed version.

 

[Peter Randziak 1,015]

Hello guys,

we are working on the issue with a high priority.

So far it seems that the freeze occurs in Database module (last release was in August) utilized by the Anti-spam engine and it seems, that the particular issue was there before as well. The mystery remains why it started to manifest just recently. The developer reproduced the freeze and works on fixing it.

 

We are sorry for the inconvenience caused.

Kind Regards, P.R.