mike.miyw

Recently i migrated from esets 4.5.15 to EFS 7.1.247 on one of my 2 HA servers that are doing HA via drbd and corosync / pacemaker. After the migration i got rung up at night as the EFS box claimed to see timeouts on the internal network connection and was not able to handle the HA anymore (so it tried to shift the services over to the other node). Trying to login via SSH i also revceived a timeout. Only thing that helped was a hard reboot of the box. The OS is a debian 10 (latest). Going into the forensics, i got the following loglines: This is what i got as first indicator of a problem Dec 2 02:33:11 miyw02-18 pacemaker-execd[12819]: warning: mysql-daemon_status_15000 process (PID 31328) timed out Dec 2 02:33:11 miyw02-18 pacemaker-execd[12819]: warning: mysql-daemon_status_15000:31328 - timed out after 15000ms This is the corresponding kernel log Dec 2 02:33:06 miyw02-18 kernel: [149346.294602] eset_rtp: wait for scanner reply timeout, path: /tmp/#sql_7d43_0.MAD, event: CLOSE, pid: 32067 Dec 2 02:33:06 miyw02-18 kernel: [149346.550679] eset_rtp: wait for scanner reply timeout, path: /var/log/pacemaker/pacemaker.log, event: CLOSE, pid: 31328 Dec 2 02:33:08 miyw02-18 kernel: [149348.598543] eset_rtp: wait for scanner reply timeout, path: /opt/splunk/_deployments/splunk_8.0.0.0/bin/splunk-optimize, event: OPEN, pid: 31329 Dec 2 02:33:09 miyw02-18 kernel: [149349.878748] eset_rtp: wait for scanner reply timeout, path: /var/log/pacemaker/pacemaker.log, event: CLOSE, pid: 31336 Dec 2 02:33:09 miyw02-18 kernel: [149349.878758] eset_rtp: wait for scanner reply timeout, path: /var/log/pacemaker/pacemaker.log, event: CLOSE, pid: 31337 Dec 2 02:33:09 miyw02-18 kernel: [149349.878766] eset_rtp: wait for scanner reply timeout, path: /var/log/pacemaker/pacemaker.log, event: CLOSE, pid: 31334 Dec 2 02:33:09 miyw02-18 kernel: [149350.134795] eset_rtp: wait for scanner reply timeout, path: /var/log/pacemaker/pacemaker.log, event: CLOSE, pid: 31341 Dec 2 02:33:09 miyw02-18 kernel: [149350.134805] eset_rtp: wait for scanner reply timeout, path: /var/log/pacemaker/pacemaker.log, event: CLOSE, pid: 31339 Dec 2 02:33:10 miyw02-18 kernel: [149351.158848] eset_rtp: wait for scanner reply timeout, path: /var/log/pacemaker/pacemaker.log, event: CLOSE, pid: 31343 Dec 2 02:33:10 miyw02-18 kernel: [149351.159260] eset_rtp: wait for scanner reply timeout, path: /var/log/pacemaker/pacemaker.log, event: CLOSE, pid: 31344 Dec 2 02:33:11 miyw02-18 kernel: [149351.670688] eset_rtp: wait for scanner reply timeout, path: /run/icinga2/icinga2.pid, event: CLOSE, pid: 911 Dec 2 02:33:11 miyw02-18 kernel: [149351.670723] eset_rtp: wait for scanner reply timeout, path: /usr/lib/nagios/plugins/check_apt, event: OPEN, pid: 31348 Dec 2 02:33:15 miyw02-18 kernel: [149355.254788] eset_rtp: wait for scanner reply timeout, path: /opt/splunk/data/var/lib/splunk/kvstore/mongo/diagnostic.data/metrics.interim.temp, event: CLOSE, pid: 22511 anyone experiencing similar issues ?

Hi, also interested in the beta

We can reproduce the issue. Issue: Forwarding a "foreign" mail to another mail hoster (gmail) sent an empty E-Mail (empty header / empty body) Following steps taken: - Disable ESET Addin in Outlook --> worked - Disabled MAil Filter --> did not work - Disabled Mail & Spam detection --> worked - Disabled Spam detection --> did not work - Disabled "add recipient from outgoing address" worked fine We do have DKIM & S/MIME enabled in our environment Thoughts: - maybe a DKIM isse (or in relation with S/MIME) - there might be a header mismatch regarding FROM receipient ? - ESET detects signatures as "malicious" and removes them - no possible way of debugging (debug log?) within eset of what exactly happens here