Krzysztof L.

@halobolahis your problem solved? Please share your solution.

I am also suffering from lack of support for ubuntu 22.04 LTS. In my case, efs installs correctly (efs-9.0.174.0.x86_64.deb), but I get segfault during efs startup. logs: May 31 12:48:11 efs. **** kernel: startd [3814]: segfault at 10 ip 00007f8c907519d2 sp 00007fff332d9210 error 4 in libcommon.so [7f8c904eb000 + 350000] May 31 12:48:11 efs. **** kernel: Code: 48 8b 04 25 28 00 00 00 48 89 04 24 bb 02 00 00 00 eb 17 0f 1f 44 00 00 49 c7 04 de 00 00 00 00 48 83 c3 01 48 83 fb 38 74 19 <49> 8b 3c de 48 85 ff 74 e5 49 c7 04 de 00 00 00 00 48 8b 07 ff> May 31 12:48:11 efs. **** systemd [1]: efs.service: Main process exited, code = dumped, status = 11 / SEGV May 31 12:48:13 efs. **** systemd [1]: efs.service: Failed with result 'core-dump'.

Hi, I also have this problem, it has occurred since 22/01/2021. Eset mail security crashes once a day (more or less every 24h). Nothing in logs... also no bt.esets_daemon.* files in /tmp/ directory. Centos 7 3.10.0-1160.11.1.el7.x86_64 # /opt/eset/esets/sbin/esets_update --version /opt/eset/esets/sbin/esets_update (esets) 4.5.15 # esets_update --verbose Update is not necessary - the installed virus signature database is current. ESETS Update utility +-+--------------------+------------------------+------------------------+ | | Module | Available version | Installed version | +-+--------------------+------------------------+------------------------+ | | loader | 1076 (20200313) | 1076 (20200313) | | | perseus | 1568.2 (20201214) | 1568.2 (20201214) | | | engine | 22709 (20210126) | 22709 (20210126) | | | archiver | 1312 (20201223) | 1312 (20201223) | | | heuristic | 1205 (20201209) | 1205 (20201209) | | | cleaner | 1214 (20200921) | 1214 (20200921) | | | horus | 7873 (20210115) | 7873 (20210115) | | | dblite | 1112 (20200928) | 1112 (20200928) | +-+--------------------+------------------------+------------------------+ A workaround is to restart eset daemon: systemctl stop esets.service /usr/bin/killall -u esets -9 systemctl start esets.service

Yes, i also confirm that everything works good for now.

I also confirm that solution from you all is working. Thank you all. (Burk code) cd /var/opt/eset/esets/lib ls -la mv em002_32.dat em002_32.dat.o cd /opt/eset/esets/sbin/ ./esets_update --verbose systemctl start esets systemctl status esets Povas i agree, we need to wait for next update.

It looks like the problem is back again. I think Is is happen after todays update at 2PM. /opt/eset/esets/sbin/esets_daemon --version /opt/eset/esets/sbin/esets_daemon (esets) 4.5.15 There is a lot of /tmp/bt.esets_daemon.* files cat bt.esets_daemon.EkR1IE signal = 11 bad addr = 0xcfc00004 /opt/eset/esets/sbin/esets_update --verbose Naruszenie ochrony pamięci (translate: Memory protection violation) Esets hung in starting loop systemctl start esets.service Job for esets.service failed because a fatal signal was delivered to the control process. See "systemctl status esets.service" and "journalctl -xe" for details. "journalctl -xe" Nov 19 15:26:16 eset-mail esets_daemon[3065]: debug[0bf90000]: ESET Security Daemon, Version 4.5.15 Nov 19 15:26:16 eset-mail esets_daemon[3065]: debug[0bf90000]: Start Antivirus scanner initialization Nov 19 15:26:16 eset-mail esets_daemon[3065]: debug[0bf90000]: Searching for section dac in configuration Nov 19 15:26:16 eset-mail esets_daemon[3065]: debug[0bf90000]: Using configuration for section dac Nov 19 15:26:20 eset-mail esets_daemon[3071]: debug[0bff0000]: ESET Security Daemon, Version 4.5.15 Nov 19 15:26:20 eset-mail esets_daemon[3071]: debug[0bff0000]: Start Antivirus scanner initialization Nov 19 15:26:20 eset-mail esets_daemon[3071]: debug[0bff0000]: Searching for section dac in configuration Nov 19 15:26:20 eset-mail esets_daemon[3071]: debug[0bff0000]: Using configuration for section dac Nov 19 15:26:23 eset-mail esets_daemon[3078]: debug[0c060000]: ESET Security Daemon, Version 4.5.15 Nov 19 15:26:23 eset-mail esets_daemon[3078]: debug[0c060000]: Start Antivirus scanner initialization (...) Server : centos 7.9.2009 (64), rebooted.

I also confirm this problem. I have now changed the file name em001_32.dat and make update. Now we will wait and watch. # /opt/eset/esets/sbin/esets_update --verbose Virus signature database has been updated successfully. ESETS Update utility +-+--------------------+------------------------+------------------------+ | | Module | Available version | Installed version | +-+--------------------+------------------------+------------------------+ |*| loader | 1074.1 (20190925) | | |*| perseus | 1555 (20190911) | | |*| engine | 20238 (20191025) | | |*| archiver | 1293 (20191004) | | |*| heuristic | 1194 (20190918) | | |*| cleaner | 1200 (20190916) | | | | | | ▒▒x▒Ƿ`▒▒x▒v▒w▒v▒0▒V▒ | | | | | | |*| horus | 7833 (20191016) | | |*| dblite | 1110 (20190827) | | +-+--------------------+------------------------+------------------------+

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

Hi Dingolino, You are not alone with this problem, this is fresh bug, go here -->

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) | +-+--------------------+------------------------+------------------------+

Michal, my mails are scanned only 8 hours a day, then I disable the postfix-eset connection and go home. By these 8 hours a day works well (last 2 days). I think this is a topic for support, but this forum is more for ordinary users and not for real support. I think we need to contact eset support directly. Michal please write more about your configuration. Perhaps it will be helpful to someone. Our postfix is on another machine than eset mail security. Both machines are virtual (vsphere 6.5). Postfix communicates with eset through the 'content filter' configuration: main.cf content_filter = smtp: [xxx.xxx.xxx.xxx]: 5555 Eset is on Centos 7.4, the following eset modules are running: esets_smtp esets_wwwi In the esets_smtp module I also activated: * Potentially unsafe apps * Potentially unwanted apps Configuration from logs (debug) : ESETS SMTP filter, Version 4.5.7 num_proc = 15 num_thrd = 2 conns_max = 25 syslog_facility = "daemon" syslog_class = "error:warning:summall:summ:partall:part:info:debug" listen_addr = "xxx.xxx.xxx.xxx" listen_port = 5555 server_addr = "yyy.yyy.yyy.yyy" server_port = 2500 add_header_xvirus = no add_header_received = no lo: 127.0.0.1 eno16777984: xxx.xxx.xxx.xxx Server is listening on xxx.xxx.xxx.xxx:5555 Any support guys here?

We have the same problem as Michal wrote. Yesterday, esets_deamon (Eset mail security for linux) entered a strange state. Telnet to eset smtp module works good but all messages goes back to postfix with status: "delivery temporarily suspended: conversation with xxx[yyy] timed out while receiving the initial server greeting". There is nothing interesting in eset logs. As an workaround we also need to restart whole virtual machine (Linux Centos 7.4). update 11:00 2017-10-04 its happened again, 3 hours after the reboot. Maybe the reason is any of newests updates (horus,engine)? # ./esets_update --verbose Update is not necessary - the installed virus signature database is current. ESETS Update utility loader 1069 (20161122) | 1069 (20161122) perseus 1530 (20170920) | 1530 (20170920) engine 16184 (20171004) | 16184 (20171004) archiver 1269 (20170913) | 1269 (20170913) heuristic 1180 (20170914) | 1180 (20170914) cleaner 1142 (20170814) | 1142 (20170814) horus 6231 (20171003) | 6231 (20171003) dblite 1093 (20170725) | 1093 (20170725) We use version 4.5.7 of eset mail security. In the list of changes for version 4.5.7 we can read: "Fixed: Server with CentOS 7 and ESET File Security for Linux 4.5.6.0 freeze in some cases" As we can see, the problem with centos 7 is not new... Maybe it has not been completely fixed?