FHolzer 0 Posted April 21, 2016 Share Posted April 21, 2016 (edited) Eset Mail Security 4.5.3 OS: Linux 2.6.32-573.22.1.el6.x86_64 x86_64 (centos 6) The Daemon randomly Freeze and my Customer cant accept or send Mails. Maillog: (delivery temporarily suspended: conversation with 127.0.0.1[127.0.0.1] timed out while receiving the initial server greeting) If i try to restart the deamon with /etc/init.d/esets restart it hangs and will never restart the service. Even when i reboot the server it cant stop the service - (forcefully restartet the VM) THIS IS ABSOLUTE HORRIBLE ! I cant work with this and already regret selling it to my customers. Acutally its just on one machine. (Installed on 2 differnt machines - should install it on 3 other Customer Mailservers) But there is technically no difference - so i dont get why one is keep failing. (after restart - 3 -5 hours later same problem) Also - there is nothing else in the Log File (or i cant find the right log file - please tell me the right one ?) in /var/log/message i can find the eset logs till it stoped working. (but just for scanned mails) But no error before - no Kernel error, no errors @ all - its looks like i just freeze Edited April 21, 2016 by FHolzer Link to comment Share on other sites More sharing options...
FHolzer 0 Posted April 22, 2016 Author Share Posted April 22, 2016 (edited) Just happend again PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 4843 esets 20 0 154m 117m 9024 S 198.1 6.3 58:05.29 esets_daemon no chance to stop the service. Forcefully shutdown. Edited April 22, 2016 by FHolzer Link to comment Share on other sites More sharing options...
FHolzer 0 Posted April 22, 2016 Author Share Posted April 22, 2016 (edited) again the process died (zombie) - Only 1 Hour - i need to uninstall this thing now top - 13:43:45 up 1:17, 1 user, load average: 1.01, 1.06, 1.03 Tasks: 173 total, 1 running, 171 sleeping, 0 stopped, 1 zombie Cpu(s): 50.2%us, 0.0%sy, 0.0%ni, 49.8%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 1914656k total, 1470988k used, 443668k free, 107564k buffers Swap: 2031612k total, 0k used, 2031612k free, 470764k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1936 esets 20 0 149m 110m 3548 S 100.1 5.9 52:28.56 esets_daemon 11 root 20 0 0 0 0 S 0.3 0.0 0:02.77 events/0 Never thougth this product can be such unstable. On my Testing enviroment it worked great. And the Loging /Debung ins a joke - or i cant find any help. So pls Forum - how can i debug an Linux Mail Security There is a /var/log/esets/ but i cant read any of these files: eventlog.dat stats.inet stats.onaccess threatlog.dat sched.dat stats.mail stats.ondemand wwwi_outputUCPTubT sess_2cc9b541556ef982b7c1ff432857a09f stats.mailpart status.dat wwwi_statusUCPTubT Edited April 22, 2016 by FHolzer Link to comment Share on other sites More sharing options...
FHolzer 0 Posted May 2, 2016 Author Share Posted May 2, 2016 no ideas how do debug this ? Link to comment Share on other sites More sharing options...
franzr77 0 Posted May 2, 2016 Share Posted May 2, 2016 could you execute this statement and send me the response: cd /opt/eset/esets/sbin ./esets_update --verbose According to ESET the problem seems to be an old horus version. i have the same problem and my autoupdate doesnot find the new one so i hat to download them manually Link to comment Share on other sites More sharing options...
gblack 0 Posted May 3, 2016 Share Posted May 3, 2016 no ideas how do debug this ? Hello, we have same problem since 20.4. Runned on 4.5.3. I had to kill esets daemons every 20 minutes. Functional workaround was downgrade to 4.0.10. Our supplier told me, that the problem is Horus antispam module. That problem is already fixed, but because of another problem with auto update it hasn't been shipped to our system. But, as I have info, that module can be updated manually (sorry, I do not have more complex information how to do it) and than should 4.5.3 work normally. Link to comment Share on other sites More sharing options...
FHolzer 0 Posted May 9, 2016 Author Share Posted May 9, 2016 could you execute this statement and send me the response: cd /opt/eset/esets/sbin ./esets_update --verbose According to ESET the problem seems to be an old horus version. i have the same problem and my autoupdate doesnot find the new one so i hat to download them manually Thanks for your time: Output: [root@srvmail01 sbin]# ./esets_update --verbose Virus signature database has been updated successfully. ESETS Update utility +-+--------------------+------------------------+------------------------+ | | Module | Available version | Installed version | +-+--------------------+------------------------+------------------------+ | | loader | 1062 (20151228) | 1062 (20151228) | |*| perseus | 1483 (20160418) | 1482 (20160330) | |*| engine | 13460 (20160509) | 13378 (20160422) | |*| archiver | 1249 (20160425) | 1248 (20160329) | | | heuristic | 1168 (20160304) | 1168 (20160304) | | | cleaner | 1120 (20160401) | 1120 (20160401) | | | horus | 2851 (20151127) | 2851 (20151127) | +-+--------------------+------------------------+------------------------+ Link to comment Share on other sites More sharing options...
kernelhacker 0 Posted May 30, 2016 Share Posted May 30, 2016 I'd really like to know, how we could update our horus-db manually, as we have the same problem here (freezing esets_daemon) and a very old horus-db: Update is not necessary - the installed virus signature database is current. ESETS Update utility +-+--------------------+------------------------+------------------------+ | | Module | Available version | Installed version | +-+--------------------+------------------------+------------------------+ | | loader | 1062 (20151228) | 1062 (20151228) | | | perseus | 1485 (20160516) | 1485 (20160516) | | | engine | 13566 (20160530) | 13566 (20160530) | | | archiver | 1249 (20160425) | 1249 (20160425) | | | heuristic | 1170 (20160425) | 1170 (20160425) | | | cleaner | 1120 (20160401) | 1120 (20160401) | | | horus | 1213P (20130221) | 1213P (20130221) | +-+--------------------+------------------------+------------------------+ mail-srv2 esets # /opt/eset/esets/sbin/esets_update --version /opt/eset/esets/sbin/esets_update (esets) 4.5.3 Thanks for your help! Stefan Pokorny Link to comment Share on other sites More sharing options...
FHolzer 0 Posted June 1, 2016 Author Share Posted June 1, 2016 (edited) Hello, Well thats funny - your output says "1213P (20130221)" for Available version. and your installed is the same. On my Systems its "2851" Available and the same is installed. (also outdated) The "manual" update Process from franzr77 didnt worked for me. After manually downloading the em021_32.dat (which should be version v3616) it says 2851 is Available and installed. Edited June 1, 2016 by FHolzer Link to comment Share on other sites More sharing options...
FHolzer 0 Posted June 1, 2016 Author Share Posted June 1, 2016 ok i think i found a way to update it: cd /var/opt/eset/esets/lib/ mv em021_32.dat em021_32.dat_old now run the Updater again: cd /opt/eset/esets/sbin ./esets_update --verbose Horus should be missing in list. Now download the new file cd /var/opt/eset/esets/lib/ wget hxxp://ftp.nod.sk/~zfarkas/%23horus/em021_32.dat now run the Updater again: cd /opt/eset/esets/sbin ./esets_update --verbose it should be updated to 3616. Link to comment Share on other sites More sharing options...
Michal Noga 0 Posted October 3, 2017 Share Posted October 3, 2017 (edited) The last post is solution? I have the same problem. Additional informations from our server: <telnet 127.0.0.1 2526> is working, Eset send my test message back to postfix. But Postfix cant send messages to esets_daemon running on 127.0.0.1:2526 Workaround is only restart my Virtual machine (Centos7.4) I tried: <echo 1 > /proc/sys/net/ipv4/tcp_window_scaling> All deferred messages are sended. But this option could't be an solution. Edited October 3, 2017 by Michal Noga Link to comment Share on other sites More sharing options...
Krzysztof L. 2 Posted October 4, 2017 Share Posted October 4, 2017 (edited) 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? Edited October 4, 2017 by Krzysztof L. Link to comment Share on other sites More sharing options...
Michal Noga 0 Posted October 4, 2017 Share Posted October 4, 2017 Hi Krysztof, For testing I try to change default value smtp_connect_timeout in main.cf from 30s to 120s. The last 24hours are our servers online without problems with freezing. However, we need a response from ESET, because our workaround may not be a good one. Link to comment Share on other sites More sharing options...
Michal Noga 0 Posted October 5, 2017 Share Posted October 5, 2017 (edited) Hi Krzysztof, our servers is running well. Did you saw something in your log files Edited October 5, 2017 by Michal Noga Link to comment Share on other sites More sharing options...
Michal Noga 0 Posted October 5, 2017 Share Posted October 5, 2017 the same situation happened again at 17:00 today Link to comment Share on other sites More sharing options...
Krzysztof L. 2 Posted October 6, 2017 Share Posted October 6, 2017 (edited) 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.cfcontent_filter = smtp: [xxx.xxx.xxx.xxx]: 5555Eset is on Centos 7.4, the following eset modules are running:esets_smtpesets_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? Edited October 6, 2017 by Krzysztof L. Link to comment Share on other sites More sharing options...
FHolzer 0 Posted October 11, 2017 Author Share Posted October 11, 2017 (edited) The Error Came back since update to 4.5.7 All Version before it worked fine (over 2 years - 0 restarts needed) So its definitively a 4.5.7 Bug. for me the error occours from time to time now (from 8hours to 20 days) This is log when the freeze starts: (conversation with 127.0.0.1[127.0.0.1] timed out while receiving the initial server greeting) this can we find if we try to restart the esets daemons (delivery temporarily suspended: connect to 127.0.0.1[127.0.0.1]:2526: Connection refused) And STILL how to read the esets LOG under /var/log/esets/ (*.dat) files. Why is there no REAL Error logging (besides the maillog and the syslog?) Edited October 11, 2017 by FHolzer typos Link to comment Share on other sites More sharing options...
Michal Noga 0 Posted October 12, 2017 Share Posted October 12, 2017 (edited) Hi all, ticket #202827 in support portal is opened. The last message from their support guy was, that he forward all collected logs from my servers to developers. We are waiting until the situation occurs. Because they need to collect logs and informations during esets_daemon malfunction. Edited October 12, 2017 by Michal Noga typo Link to comment Share on other sites More sharing options...
FHolzer 0 Posted October 13, 2017 Author Share Posted October 13, 2017 (edited) Hi Michal. Thanks for your effort! Please keep us informed. ------------ I Just had this Error on a Centos 6.x with a 4.5.3 Version. Im not sure if its related. (i personally dont think so) Versions: +-+--------------------+------------------------+------------------------+ | | Module | Available version | Installed version | +-+--------------------+------------------------+------------------------+ | | loader | 1069 (20161122) | 1069 (20161122) | | | perseus | 1530 (20170920) | 1530 (20170920) | | | engine | 16234 (20171013) | 16234 (20171013) | | | archiver | 1269 (20170913) | 1269 (20170913) | | | heuristic | 1180 (20170914) | 1180 (20170914) | | | cleaner | 1145 (20170906) | 1145 (20170906) | | | horus | 3616 (20160429) | 3616 (20160429) | +-+--------------------+------------------------+------------------------+ Looks like its the old 4.5.3 Bug (no Horus Update) - but it worked for over a year now without a problem. And 4.5.7 keeps failing - so i dont will upgrade it for now. Edited October 13, 2017 by FHolzer Link to comment Share on other sites More sharing options...
FHolzer 0 Posted October 13, 2017 Author Share Posted October 13, 2017 (edited) it just happend again.CentOS: centos-release-7-3.1611.el7.centos.x86_64Mail Security Version: /opt/eset/esets/sbin/esets_daemon (esets) 4.5.7 Components: [root@mail sbin]# ./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 | 1530 (20170920) | 1530 (20170920) | | | engine | 16236 (20171013) | 16236 (20171013) | | | archiver | 1269 (20170913) | 1269 (20170913) | | | heuristic | 1180 (20170914) | 1180 (20170914) | | | cleaner | 1142 (20170814) | 1142 (20170814) | | | horus | 6282 (20171013) | 6282 (20171013) | | | dblite | 1093 (20170725) | 1093 (20170725) | +-+--------------------+------------------------+------------------------+ Error in maillog: relay=127.0.0.1[127.0.0.1]:2526, delay=1651, delays=1351/0.02/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) Status eset Daemon: [root@mail ~]# systemctl status esets ● esets.service - ESET Scanner Daemon Loaded: loaded (/usr/lib/systemd/system/esets.service; enabled; vendor preset: disabled) Active: active (running) since Wed 2017-10-11 19:39:29 CEST; 1 day 20h ago Process: 859 ExecStart=/opt/eset/esets/sbin/esets_daemon (code=exited, status=0/SUCCESS) Main PID: 2578 (esets_daemon) CGroup: /system.slice/esets.service ├─2578 /opt/eset/esets/sbin/esets_daemon ├─2679 /opt/eset/esets/sbin/esets_daemon ├─2680 /opt/eset/esets/lib/esets_smtp ├─2681 /opt/eset/esets/lib/esets_wwwi └─2691 /opt/eset/esets/lib/esets_smtp Oct 13 14:00:26 mail.xxxx-xxxx.com esets_daemon[2679]: summ[0a7701e4]: vdb=35048, agent=smtp, name="from: "xxxx" <sss@ssss.com> to: "xxx" <xxxx@xxxx-xxxx.com> …d" Oct 13 14:00:26 mail.xxxx-xxxx.com esets_smtp[2691]: summ[0a830101]: action="accepted" Oct 13 14:07:15 mail.xxxx-xxxx.com esets_daemon[2679]: summ[0a7702e5]: vdb=35048, agent=smtp, name="from: "xxxx <sss@xxxx-xxxx.com> to: "xxx, xxx" <xxx.xxr@…d" Oct 13 14:07:15 mail.xxxx-xxxx.com esets_smtp[2691]: summ[0a830201]: action="accepted" Oct 13 14:13:29 mail.xxxx-xxxx.com esets_daemon[2679]: summ[0a7701e6]: vdb=35048, agent=smtp, name="from: "xxx" <xxx@xxxx.xxx.com> to: office@xxxx-xxxx.com with subject Jetzt K...p="accepted" Oct 13 14:13:29 mail.xxxx-xxxx.com esets_smtp[2691]: summ[0a830201]: action="accepted" Oct 13 14:14:24 mail.xxxx-xxxx.com esets_daemon[2679]: summ[0a7702e7]: vdb=35048, agent=smtp, name="from: "xxx" <info26@xxxx.es> to: office@xxxx-xxxx.com with subject Curs...p="accepted" Oct 13 14:14:24 mail.xxxx-xxxx.com esets_smtp[2691]: summ[0a830101]: action="accepted" Oct 13 14:26:51 mail.xxxx-xxxx.com esets_daemon[2679]: summ[0a7701e8]: vdb=35048, agent=smtp, name="from: "xxxx" <xxx@xxx.de> to: xxxx <xxx@sss…d" Oct 13 14:26:51 mail.xxxx-xxxx.com esets_smtp[2691]: summ[0a830101]: action="accepted" Hint: Some lines were ellipsized, use -l to show in full. PIDs running: [root@mail ~]# ps -C esets_daemon PID TTY TIME CMD 2578 ? 00:00:07 esets_daemon 2679 ? 01:46:52 esets_daemon you cant restart/stop the service via systemctl systemctl stop esets via /etc/init.d/esets stop its working (kind of) - its stops one of the PIDs. [root@mail ~]# /etc/init.d/esets stop Stopping esets (via systemctl): [ OK ] [root@mail ~]# ps -C esets_daemon PID TTY TIME CMD 2679 ? 01:46:53 esets_daemon you have to kill the remaining PID: [root@mail ~]# kill -9 2679 [root@mail ~]# ps -C esets_daemon PID TTY TIME CMD After that you can start the daemons again: [root@mail ~]# systemctl start esets [root@mail ~]# systemctl status esets ● esets.service - ESET Scanner Daemon Loaded: loaded (/usr/lib/systemd/system/esets.service; enabled; vendor preset: disabled) Active: active (running) since Fri 2017-10-13 16:06:31 CEST; 10s ago Process: 53297 ExecStart=/opt/eset/esets/sbin/esets_daemon (code=exited, status=0/SUCCESS) Main PID: 53298 (esets_daemon) CGroup: /system.slice/esets.service ├─53298 /opt/eset/esets/sbin/esets_daemon ├─53299 /opt/eset/esets/sbin/esets_daemon ├─53300 /opt/eset/esets/lib/esets_smtp ├─53301 /opt/eset/esets/lib/esets_wwwi └─53312 /opt/eset/esets/lib/esets_smtp Oct 13 16:06:27 mail.xxxxx.com systemd[1]: Starting ESET Scanner Daemon... Oct 13 16:06:31 mail.xxxxx.com systemd[1]: Started ESET Scanner Daemon. Both daemons started - check it -> [root@mail ~]# ps -C esets_daemon PID TTY TIME CMD 53298 ? 00:00:00 esets_daemon 53299 ? 00:00:00 esets_daemon after that everything works fine again. (real tests and maillog check) Edited October 13, 2017 by FHolzer OS end ESET Versions Link to comment Share on other sites More sharing options...
Michal Noga 0 Posted October 13, 2017 Share Posted October 13, 2017 (edited) Hi FHolzer, I have a tool from ESET, which collects all necessary data, not only logs. This information is required for troubleshooting by developers. Yours log contains less information, that is needed. I will find out,whether I can provide this tool for you. EDIT: I have already asked a few minutes ago Edited October 13, 2017 by Michal Noga Update comment Link to comment Share on other sites More sharing options...
FHolzer 0 Posted October 13, 2017 Author Share Posted October 13, 2017 (edited) do be honest, this Bug is so critical - it should never happend. But it did - Twice in 1 Year. Im not sure if i should resell Linux Products from ESET in the Future - since im not sure if the product is stable enough. All i have now are angry Customers who complain about "no working Mailserver" - AGAIN. But lets hope They can fix it very soon or i need to uninstall it. Edited October 13, 2017 by FHolzer Link to comment Share on other sites More sharing options...
Michal Noga 0 Posted October 16, 2017 Share Posted October 16, 2017 Dear all, you can collect information with this script: Script for collecting info @FHolzer Yes you are right. My current "workaround" is : Zabbix can check postfix queue (deferred), then if count of messages are bigger than 150, Zabbix can restart whole server. BR Link to comment Share on other sites More sharing options...
Boban 1 Posted November 2, 2017 Share Posted November 2, 2017 It's not necessary to restart whole server, you can only kill process by killall -u esets -9 and then start the service Link to comment Share on other sites More sharing options...
FHolzer 0 Posted November 2, 2017 Author Share Posted November 2, 2017 (edited) it should be fixed by today. (02.11.2017) Developers informed me that 4.5.9 was released today which includes a bugfix for this problem. Edited November 2, 2017 by FHolzer Link to comment Share on other sites More sharing options...
Recommended Posts