Jump to content

EFS causes drbd/pacemaker setup to crash


Recommended Posts

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 ? 

 

Link to post
Share on other sites
  • ESET Moderators

Hello @mike.miyw,

please provide us with the logs collected by collect_logs.sh script available at /opt/eset/efs/sbin/  https://help.eset.com/efs/7/en-US/?collect-logs.html 

and output from strace so we can have it checked.

You can upload the logs to a safe location and send me a private message with download details.

Peter

Link to post
Share on other sites
  • 4 weeks later...
  • 2 weeks later...
  • ESET Moderators

Hello @Acc-Eset,

well running the ESET security products in Chroot is not supported, even if you do not notice any issues with it that does not mean it actually works properly.

 

Chroot is a feature that can be "enabled" for selected processes. According to chroot(2):

In particular, it is not intended to be used for any kind of security purpose, neither to fully sandbox a process nor to restrict filesystem system calls.

So it seems the way to resolve the issue is to configure the Chroot to exclude the ESETs processes.

 

Please share the results with us, 

Peter

Link to post
Share on other sites

Hello,

I'm not sure i understand your answer.

I installed Eset security products in Debian 10 normally, like a Debian 9 and all the others servers.

The problem appeared after a reboot. So i wasn't in chroot, or maybe i misunderstood ?

Thanks

 

Link to post
Share on other sites

Archived

This topic is now archived and is closed to further replies.

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...