On Linux syslog fills with 'eset_rtp: wait for scanner reply timeout' (and machine becomes unresponsive)

[Variety8037 0]

What is to blame here? Is it a local issue or an issue with an ESET server under high load?

Until I understand where the locus of this failure mode is, I cannot justify the time spent looking at this issue, and must stop efs.service.

I saw a couple other topics on this, but never a clear statement or outcome, or a resulting KB to spread the knowledge about this error message which I'm sure a lot of people have experienced, and will continue to experience.

Related ticket I filed today to get the ball rolling with support: #00520204
 

[Marcos 5,274]

Logs will need to be added to the support ticket. I've tried it myself and collect_logs.sh was there no matter if I installed ESET File Security or ESET Endpoint Antivirus on Ubuntu. Do you use a different Linux distribution? Couldn't it be that it's a 1 or 2-core CPU system?

[Variety8037 0]

It's PoP OS, which is an Ubuntu derivative.

Weird, now I look for collect_logs.sh and it is present. Never mind.

Is there a particular file from the collected logs tar.gz that I should post?

I cannot post the entire tar gz here because it contains information that has not been anonymized (syslog for example). But I could imagine doing that in the support ticket if there is an upload capability there.

[Marcos 5,274]

Don't post it here but provide the logs to technical support when requested after raising a support ticket. The logs will need to be checked by developers. Can you confirm that it's a system with more than 2 CPU cores?

[Variety8037 0]

I have 4 physical cores (8 logical cores).

The support ticket is raised as #00520204, so the ball is rolling on that side as well.

[Marcos 5,274]

I would check logs myself as well. You can upload the generated archive here if smaller than 200 MB or upload it to a file sharing service and drop me a personal message with a download link. Attachments uploaded here can be accessed only by ESET staff.

[Variety8037 0]

The collect_logs.sh was creating a 32MB tar.gz, I had to find a better way.

I cleaned /var/log and looked at what's happening shortly after starting efs.service. It does not take long for the first rtp timeout to show up. Please note that I have scrubbed user and host info

Quote

$ tail -f /var/log/syslog
...
Apr 22 09:56:42 scrubbed systemd[1]: Starting ESET Server Security...
Apr 22 09:56:44 scrubbed kernel: [21539.897993] eset_rtp: registered syscall handlers
Apr 22 09:56:44 scrubbed kernel: [21539.898166] ESET Real-time file system protection module 2.0 <www.eset.com>
Apr 22 09:56:44 scrubbed systemd[1]: Started ESET Server Security.
Apr 22 09:56:54 scrubbed kernel: [21550.407041] eset_rtp: wait for scanner reply timeout, path: /home/scrubbed/Vault/Home/dotAssets/gitconfig-usedelta, event: OPEN, id: 47 pid: 68191
Apr 22 09:56:54 scrubbed kernel: [21550.407041] eset_rtp: wait for scanner reply timeout, path: /home/scrubbed/.EncryptedVault/S_luso-LVvyULp5mQWDMlg/w8xIO2-YVh94PGJgAoFVgw/-nCtnCj8SDglSe77MN4LBfbQxxOPbgha1HC7gC6xF58, event: OPEN, id: 48 pid: 5021
Apr 22 09:57:01 scrubbed cron[1323]: (*system*eset-efs) RELOAD (/etc/cron.d/eset-efs)
Apr 22 09:57:09 scrubbed systemd[1]: Stopping ESET Server Security...
Apr 22 09:57:11 scrubbed kernel: [21567.270769] eset_rtp: unregistered syscall handlers
Apr 22 09:57:12 scrubbed systemd[1]: efs.service: Deactivated successfully.
Apr 22 09:57:12 scrubbed systemd[1]: Stopped ESET Server Security.
Apr 22 09:57:12 scrubbed systemd[1]: efs.service: Consumed 9.646s CPU time.

~/.EncryptedVault is the cipherdir for a gocryptfs user mounted encrypted directory of mine.
 

Quote

$ mount | grep gocryptfs
/home/scrubbed/.EncryptedVault on /home/scrubbed/Vault type fuse.gocryptfs (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000,max_read=131072)

The allow_other mount options is not present. So not even root can read the files under Vault. Could this be triggering the problem?

I doubt it, because if I keep looking in the syslog, there are timeouts happening on paths that have nothing to do with Vault
 

Quote

Apr 22 10:12:03 scrubbed rtkit-daemon[2092]: Supervising 14 threads of 8 processes of 2 users.
...
Apr 22 10:13:35 scrubbed kernel: [22551.610178] eset_rtp: wait for scanner reply timeout, path: /memfd:pulseaudio (deleted), event: CLOSE, id: 15286 pid: 5363
...
Apr 22 10:13:35 scrubbed kernel: [22551.610233] eset_rtp: wait for scanner reply timeout, path: /memfd:pulseaudio (deleted), event: CLOSE, id: 15287 pid: 75156
...
Apr 22 10:13:46 scrubbed kernel: [22561.850138] eset_rtp: wait for scanner reply timeout, path: /memfd:mozilla-ipc (deleted), event: CLOSE, id: 15303 pid: 75554
Apr 22 10:13:46 scrubbed kernel: [22561.850145] eset_rtp: wait for scanner reply timeout, path: /memfd:pulseaudio (deleted), event: CLOSE, id: 15301 pid: 75156
Apr 22 10:13:46 scrubbed kernel: [22561.850162] eset_rtp: wait for scanner reply timeout, path: /home/scrubbed/.librewolf/yy7rk7pb.default-release/storage/default/https+++forum.eset.com/ls/data.sqlite, event: CLOSE, id: 15300 pid: 22879
Apr 22 10:13:46 scrubbed kernel: [22561.850190] eset_rtp: wait for scanner reply timeout, path: /memfd:pulseaudio (deleted), event: CLOSE, id: 15302 pid: 5363
Apr 22 10:13:56 scrubbed kernel: [22572.089902] eset_rtp: wait for scanner reply timeout, path: /memfd:pulseaudio (deleted), event: CLOSE, id: 15319 pid: 75156
Apr 22 10:13:56 scrubbed kernel: [22572.089906] eset_rtp: wait for scanner reply timeout, path: /memfd:pulseaudio (deleted), event: CLOSE, id: 15321 pid: 75156
...
Apr 22 10:13:56 scrubbed kernel: [22572.089906] eset_rtp: wait for scanner reply timeout, path: /home/scrubbed/.librewolf/yy7rk7pb.default-release/cookies.sqlite-wal, event: CLOSE, id: 15317 pid: 22879