esets_daemon freeze - 2018 version

[FHolzer 0]

It looks like the Problem is back since 25/10/2018.
Also confirmed from the User Krzysztof L.

Same error pattern as in the old topic.
The daemon runs for 10 - 30 seconds and than is "dead"

 

i Updated everything so far but problem persists.

[root@srvmail01 ~]# /opt/eset/esets/sbin/esets_daemon --version
/opt/eset/esets/sbin/esets_daemon (esets) 4.5.11

./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             |       18289 (20181028) |       18289 (20181028) |
| | archiver           |        1278 (20180924) |        1278 (20180924) |
| | heuristic          |        1190 (20180924) |        1190 (20180924) |
| | cleaner            |        1170 (20181025) |        1170 (20181025) |
| | horus              |        7778 (20181017) |        7778 (20181017) |
| | dblite             |        1103 (20180629) |        1103 (20180629) |
+-+--------------------+------------------------+------------------------+

 

Edited October 29, 2018 by FHolzer

[FHolzer 0]

just made an Virus Database Update again.
It Updated the engine from 18289 to 18291.
the Update is from today - so it looks like it just was released.

 

[root@srvmail01 sbin]# ./esets_update --verbose
Virus signature database has been updated successfully.
ESETS Update utility
+-+--------------------+------------------------+------------------------+
| | Module             | Available version      | Installed version      |
+-+--------------------+------------------------+------------------------+
| | loader             |        1072 (20180813) |        1072 (20180813) |
| | perseus            |        1543 (20180927) |        1543 (20180927) |
|*| engine             |       18291 (20181029) |       18289 (20181028) |
| | archiver           |        1278 (20180924) |        1278 (20180924) |
| | heuristic          |        1190 (20180924) |        1190 (20180924) |
| | cleaner            |        1170 (20181025) |        1170 (20181025) |
| | horus              |        7778 (20181017) |        7778 (20181017) |
| | dblite             |        1103 (20180629) |        1103 (20180629) |
+-+--------------------+------------------------+------------------------+

 

 

now the daemons run since ~45 minutes.
but as we know - it can be hanging later.
Will report back later.

to all ending here - Update your databases via:
 

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

 

[Krzysztof L. 2]

Yes i confirm this bug. My system is:

CentOS Linux release 7.5.1804 (Core)
(esets) 4.5.11

But is also happen on esets 4.5.9 (i just updated it to 4.5.11). First occurred of this bug is 25/10/2018 at 4pm. Now its happen about one/two times a day.

To Eset support team - Please check what are you changed in last week. In my recognition only engine module was changed in this day.

While esets daemon is freezed then i UNABLE to restart it by command:

# systemctl restart esets.service

i need to:

# /usr/bin/killall -u esets -9

and then start eset again.

Some other hints...

eset.log on freezed daemon (4.5.11)
 

Oct 28 20:53:41 eset-mail esets_daemon[1850]: debug[07340000]: Sessions processing done
Oct 28 20:53:41 eset-mail esets_daemon[1850]: debug[07340000]: Waiting for child processes...

eset.log for version 4.5.9
 

Oct 25 21:23:35 eset-mail esets_daemon[1081]: error[04390000]: Child process esets_daemon[1332] did not handle signal 6, restart in 0 seconds

other errors in eset.logs (this happen when i try to restart eset after freeze)
 

Oct 27 23:33:02 eset-mail esets_daemon[1443]: error[05a30000]: Cannot open file /var/log/esets/threatlog.dat: Connection timed out
Oct 27 23:34:04 eset-mail esets_daemon[1522]: error[05f20000]: Cannot open file /var/log/esets/threatlog.dat: Connection timed out
Oct 27 23:34:27 eset-mail esets_daemon[1578]: error[062a0000]: Cannot open file /var/log/esets/threatlog.dat: Connection timed out

sometimes also in /tmp direcotry Eset create files just like:

-rw------- 1 esets esets  29 10-27 22:09 bt.esets_daemon.KmBKPG

# cat bt.esets_daemon.KmBKPG

signal = 6
bad addr = 0x6e7f

Now (10:53 2018-10-29), as FHolzer said, I launched the updates manually

+-+--------------------+------------------------+------------------------+
| | Module             | Available version      | Installed version      |
+-+--------------------+------------------------+------------------------+
| | loader             |        1072 (20180813) |        1072 (20180813) |
| | perseus            |        1543 (20180927) |        1543 (20180927) |
| | engine             |       18291 (20181029) |       18291 (20181029) |
| | archiver           |        1278 (20180924) |        1278 (20180924) |
| | heuristic          |        1190 (20180924) |        1190 (20180924) |
| | cleaner            |        1170 (20181025) |        1170 (20181025) |
| | horus              |        7778 (20181017) |        7778 (20181017) |
| | dblite             |        1103 (20180629) |        1103 (20180629) |
+-+--------------------+------------------------+------------------------+

 

Edited October 29, 2018 by Krzysztof L.

[Peter Randziak 1,160]

Hello @FHolzer and @Krzysztof L.,

We need the dumps to be able to look into it, please continue in a following way:

1. Stop the esets service

2.run command ulimit -c unlimited

to enable complete dumps

3. Please run the esets_daemon with the strace parameter

"strace -ffo esets_daemon.txt -s 256 /opt/eset/esets/sbin/esets_daemon"

4. Wait till issue occurs again and pack  all esets_daemon.txt* and /tmp/bt.* files including fresh info_get command logs

5. Upload them to a safe location and send me a PM with a reference to this forum topic to analyze it.

 

We apologize for the inconvenience caused.

Thank you, P.R.

[FHolzer 0]

Quote

including fresh info_get command logs

what do you mean with ` including fresh info_get command logs ` ?

Edit - oh you mean that -> https://support.eset.com/kb6159/?locale=en_US&viewlocale=en_US
got you

----

also there is a new engine version again
 

| | engine             |       18293 (20181029) |       18293 (20181029) |

 

Edited October 29, 2018 by FHolzer
new enginge version

[Marcos 5,238]

Was the issue resolved after updating the horus module to v7779?

[FHolzer 0]

first yes looks like there was also a horus update.
im on
 

 | horus              |        7779 (20181029) |        7779 (20181029) |

im not sure if the issue was resolved with that - since the error occurs from 10minutes after starting the daemon - up to 24hours and more.
we will see.

was there a fix in v7779 cause you are mentioning it ?

[Marcos 5,238]

1 hour ago, FHolzer said:

Was there a fix in v7779 cause you are mentioning it ?

Not really. We simply reverted the module to the previous version since it was most likely this one which caused the issues.

[FHolzer 0]

for now it looks stable.
i will inform you if it crashes again.

Thanks for your time!

Edited October 30, 2018 by FHolzer

[Krzysztof L. 2]

It is now 24 hours of stable working , few days more and we will be full stable.

Thank you.

[CircleSquare 0]

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

 

[FHolzer 0]

hi @CircleSquare !!

can you post us your output from ?

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

[CircleSquare 0]

./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 ?

[CircleSquare 0]

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