Jump to content

esets_daemon freeze


Recommended Posts

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 by FHolzer
Link to comment
Share on other sites

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 by FHolzer
Link to comment
Share on other sites

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 by FHolzer
Link to comment
Share on other sites

  • 2 weeks later...

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

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

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

  • 3 weeks later...

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

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 by FHolzer
Link to comment
Share on other sites

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

  • 1 year later...

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 by Michal Noga
Link to comment
Share on other sites

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 by Krzysztof L.
Link to comment
Share on other sites

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

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?

 

Edited by Krzysztof L.
Link to comment
Share on other sites

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 by FHolzer
typos
Link to comment
Share on other sites

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 by Michal Noga
typo
Link to comment
Share on other sites

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 by FHolzer
Link to comment
Share on other sites

it just happend again.

CentOS: centos-release-7-3.1611.el7.centos.x86_64
Mail 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 by FHolzer
OS end ESET Versions
Link to comment
Share on other sites

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 by Michal Noga
Update comment
Link to comment
Share on other sites

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 by FHolzer
Link to comment
Share on other sites

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

  • 3 weeks later...

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 by FHolzer
Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...