CircleSquare

it now runs for more than one day stable. would that be only a missing fix in Horus DB from previously? really cool that we do the upgrade to 4.5.11.0 on 18.10.2018 so it feels like a fail in core software itself :D Greetings

./esets_update --verbose Update is not necessary - the installed virus signature database is current. ESETS Update utility +-+--------------------+------------------------+------------------------+ | | Module | Available version | Installed version | +-+--------------------+------------------------+------------------------+ | | loader | 1072 (20180813) | 1072 (20180813) | | | perseus | 1543 (20180927) | 1543 (20180927) | | | engine | 18305 (20181031) | 18305 (20181031) | | | archiver | 1278 (20180924) | 1278 (20180924) | | | heuristic | 1190 (20180924) | 1190 (20180924) | | | cleaner | 1170 (20181025) | 1170 (20181025) | | | horus | 7779 (20181029) | 7779 (20181029) | | | dblite | 1103 (20180629) | 1103 (20180629) | +-+--------------------+------------------------+------------------------+ for sure, heres is the result ?

got the same problem here, after try to upgrade to 4.5.11.0 from 4.5.9 (the holy one) Deamon: esets.service - ESET Scanner Daemon Loaded: loaded (/lib/systemd/system/esets.service; enabled) Active: inactive (dead) since Sat 2018-10-27 19:03:56 CEST; 3 days ago Main PID: 13980 (code=exited, status=0/SUCCESS) Oct 27 19:03:06 xxx.de esets_daemon[13980]: error[369c0000]: Child process esets_daemon[13981] did not handle signal 6, restart in 0 seconds Oct 27 19:03:11 xxx.de esets_daemon[13980]: error[369c0000]: Child process esets_daemon[7758] did not handle signal 6, restart in 0 seconds Oct 27 19:03:16 xxx.de esets_daemon[13980]: error[369c0000]: Child process esets_daemon[7772] did not handle signal 6, restart in 0 seconds Oct 27 19:03:20 xxx.de esets_daemon[13980]: error[369c0000]: Child process esets_daemon[7863] did not handle signal 6, restart in 0 seconds Oct 27 19:03:25 xxx.de esets_daemon[13980]: error[369c0000]: Child process esets_daemon[7877] did not handle signal 6, restart in 0 seconds Oct 27 19:03:30 xxx.de esets_daemon[13980]: error[369c0000]: Child process esets_daemon[7960] did not handle signal 6, restart in 0 seconds Oct 27 19:03:35 xxx.de esets_daemon[13980]: error[369c0000]: Child process esets_daemon[7974] did not handle signal 6, restart in 0 seconds Oct 27 19:03:40 xxx.de esets_daemon[13980]: error[369c0000]: Child process esets_daemon[8058] did not handle signal 6, restart in 0 seconds Oct 27 19:03:45 xxx.de esets_daemon[13980]: error[369c0000]: Child process esets_daemon[8072] did not handle signal 6, restart in 0 seconds Oct 27 19:03:50 xxx.de esets_daemon[13980]: error[369c0000]: Child process esets_daemon[8155] did not handle signal 6, restart in 0 seconds after reading your topic and posts i give em a second try today. now it is upgrading .. looking on this later that day. filter is bypassed while it looks stable to me. why every time in my holidays? Greetings

good point full log message: Dec 11 06:51:58 hots postfix/smtp[24645]: E9B7D11440A6: to=<xxx@xxx.de>, relay=127.0.0.1[127.0.0.1]:2526, delay=72594, delays=72294/0.04/300/0, dsn=4.4.2, status=deferred (conversation with 127.0.0.1[127.0.0.1] timed out while receiving the initial server greeting) same error other sound .. but after the downgrade it will be an false positive in our case

version is downgraded ... we used the prerelease-updates setting why it would returns to regular update channel?

hi everyone, it happens again on Sunday

we now run an test with the new dblite version over prerelease update channel. Greetings

Hi Randziak, tanks for the update, you mean to replace "em022_32.dat" files under "/var/opt/eset/esets/lib/" ? we plan to run a test next Friday when workload goes down a bit. Greetings

tanks for feedback, so maybe the problem is delivered with an signature update from anti-spam module? in our case it happens with 4.5.7.0 without any changes off software. Greetings

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

do you got anything new from tech support ?

we do stop ERA Agent services but the problem is still happen´s after some hours of processing mail. 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

hi iberes, it is only turned red while number is different up the version 4.5.9 is the newest at this moment Greetings

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

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