mensch 0 Posted April 14 Share Posted April 14 Hello, we have a RedHat EL 8.5 server running containers in rootless docker mode. If On access Scanning is enabled it slows down the containers a lot AND we see the following eset_rtp messages in /var/log/messages: Apr 14 09:27:03 vm00947 kernel: eset_rtp(ertp_wait_for_result): wait for scanner reply timeout, id: -1, path: /etc/passwd, size: 1225, event: OPEN, command: runc:[2:INIT], pid: 82794 Apr 14 09:27:13 vm00947 kernel: eset_rtp(ertp_wait_for_result): wait for scanner reply timeout, id: -1, path: /etc/group, size: 715, event: OPEN, command: runc:[2:INIT], pid: 82794 Apr 14 09:27:24 vm00947 kernel: eset_rtp(ertp_wait_for_result): wait for scanner reply timeout, id: -1, path: /etc/group, size: 715, event: OPEN, command: runc:[2:INIT], pid: 82794 Apr 14 09:27:34 vm00947 kernel: eset_rtp(ertp_wait_for_result): wait for scanner reply timeout, id: -1, path: /bin/busybox, size: 824984, event: EXEC, command: docker-entrypoi, pid: 82839 Apr 14 09:27:34 vm00947 kernel: eset_rtp(ertp_wait_for_result): wait for scanner reply timeout, id: -1, path: /bin/busybox, size: 824984, event: EXEC, command: docker-entrypoi, pid: 82838 Apr 14 09:27:44 vm00947 kernel: eset_rtp(ertp_wait_for_result): wait for scanner reply timeout, id: -1, path: /docker-entrypoint.d/10-listen-on-ipv6-by-default.sh, size: 1961, event: OPEN, command: 10-listen-on-ip, pid: 82847 Apr 14 09:27:54 vm00947 kernel: eset_rtp(ertp_wait_for_result): wait for scanner reply timeout, id: -1, path: /bin/busybox, size: 824984, event: EXEC, command: 10-listen-on-ip, pid: 82850 Apr 14 09:28:04 vm00947 kernel: eset_rtp(ertp_wait_for_result): wait for scanner reply timeout, id: -1, path: /docker-entrypoint.d/20-envsubst-on-templates.sh, size: 1037, event: OPEN, command: 20-envsubst-on-, pid: 82855 Apr 14 09:28:15 vm00947 kernel: eset_rtp(ertp_wait_for_result): wait for scanner reply timeout, id: -1, path: /bin/busybox, size: 824984, event: EXEC, command: 20-envsubst-on-, pid: 82865 Apr 14 09:28:25 vm00947 kernel: eset_rtp(ertp_wait_for_result): wait for scanner reply timeout, id: -1, path: /bin/busybox, size: 824984, event: EXEC, command: 20-envsubst-on-, pid: 82875 Apr 14 09:28:25 vm00947 kernel: eset_rtp(ertp_wait_for_result): wait for scanner reply timeout, id: -1, path: /bin/busybox, size: 824984, event: EXEC, command: 20-envsubst-on-, pid: 82874 Apr 14 09:28:35 vm00947 kernel: eset_rtp(ertp_wait_for_result): wait for scanner reply timeout, id: -1, path: /docker-entrypoint.d/30-tune-worker-processes.sh, size: 4613, event: OPEN, command: 30-tune-worker-, pid: 82878 Apr 14 09:28:45 vm00947 kernel: eset_rtp(ertp_wait_for_result): wait for scanner reply timeout, id: -1, path: /bin/busybox, size: 824984, event: EXEC, command: 30-tune-worker-, pid: 82889 Apr 14 09:28:56 vm00947 kernel: eset_rtp(ertp_wait_for_result): wait for scanner reply timeout, id: -1, path: /docker-entrypoint.sh, size: 1202, event: OPEN, command: docker-entrypoi, pid: 82794 Apr 14 09:29:06 vm00947 kernel: eset_rtp(ertp_wait_for_result): wait for scanner reply timeout, id: -1, path: /etc/passwd, size: 1225, event: OPEN, command: nginx, pid: 82794 Apr 14 09:29:16 vm00947 kernel: eset_rtp(ertp_wait_for_result): wait for scanner reply timeout, id: -1, path: /etc/group, size: 715, event: OPEN, command: nginx, pid: 82794 Apr 14 09:29:26 vm00947 kernel: eset_rtp(ertp_wait_for_result): wait for scanner reply timeout, id: -1, path: /etc/group, size: 715, event: OPEN, command: nginx, pid: 82932 The commands AND paths mentioned in the eset_rtp logs above ARE mostly inside the container. For example: "nginx" is running in the container. Kernel version: [mch@vm00947 ~]$ uname -a Linux vm00947.ict-beheer.local 4.18.0-348.20.1.el8_5.x86_64 #1 SMP Tue Mar 8 12:56:54 EST 2022 x86_64 x86_64 x86_64 GNU/Linux Eset version: [mch@vm00947 ~]$ rpm -qa |grep efs efs-9.0.174.0-1.x86_64 Docker version: [mch@vm00947 ~]$ rpm -qa |grep docker docker-ce-cli-20.10.14-3.el8.x86_64 docker-ce-20.10.14-3.el8.x86_64 docker-scan-plugin-0.17.0-3.el8.x86_64 docker-ce-rootless-extras-20.10.14-3.el8.x86_64 Docker info: [mch@vm00947 ~]$ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 73c8d12b2c2e nginxdemos/hello "/docker-entrypoint.…" 42 hours ago Up 9 minutes 0.0.0.0:49153->80/tcp, :::49153->80/tcp relaxed_ride [mch@vm00947 ~]$ docker info Client: Context: default Debug Mode: false Plugins: app: Docker App (Docker Inc., v0.9.1-beta3) buildx: Docker Buildx (Docker Inc., v0.8.1-docker) scan: Docker Scan (Docker Inc., v0.17.0) Server: Containers: 1 Running: 1 Paused: 0 Stopped: 0 Images: 1 Server Version: 20.10.14 Storage Driver: fuse-overlayfs Logging Driver: json-file Cgroup Driver: none Cgroup Version: 1 Plugins: Volume: local Network: bridge host ipvlan macvlan null overlay Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog Swarm: inactive Runtimes: io.containerd.runc.v2 io.containerd.runtime.v1.linux runc Default Runtime: runc Init Binary: docker-init containerd version: 3df54a852345ae127d1fa3092b95168e4a88e2f8 runc version: v1.0.3-0-gf46b6ba init version: de40ad0 Security Options: seccomp Profile: default rootless Kernel Version: 4.18.0-348.20.1.el8_5.x86_64 Operating System: Red Hat Enterprise Linux 8.5 (Ootpa) OSType: linux Architecture: x86_64 CPUs: 1 Total Memory: 808.6MiB Name: vm00947.ict-beheer.local ID: 3KQF:IYRP:ZPZZ:XBJ3:HFBC:3KG5:SGL5:IU6Z:HXTN:WWWR:3QEL:UEAZ Docker Root Dir: /home/mch@XXXXXXXXXXXXXXX/.local/share/docker Debug Mode: false HTTP Proxy: hxxp://XXXXXXXXXXXX:3128 HTTPS Proxy: hxxp://XXXXXXXXXXXX:3128 No Proxy: localhost,127.0.0.1 Registry: https://index.docker.io/v1/ Labels: Experimental: false Insecure Registries: 127.0.0.0/8 Live Restore Enabled: false WARNING: Running in rootless-mode without cgroups. To enable cgroups in rootless-mode, you need to boot the system in cgroup v2 mode. WARNING: bridge-nf-call-iptables is disabled WARNING: bridge-nf-call-ip6tables is disabled Quote Link to comment Share on other sites More sharing options...
mskb 0 Posted June 2 Share Posted June 2 We have faced similar problem too. Did you find any solution about this problem？ Now, we have contacted to ESET support, but not found any solution yet. Quote Link to comment Share on other sites More sharing options...
mensch 0 Posted June 24 Author Share Posted June 24 @mskb: No, we don't have a solution. I hope ESET can do something about it. We worked around the problem by disabling realtime scanning. Instead that we scheduled a nightly full scan. Quote Link to comment Share on other sites More sharing options...
mskb 0 Posted September 9 Share Posted September 9 @mensch Thank you for your reply. We didn't had get any solutions from ESET support. Eventually, we had checked log(/var/log/messages) and processes(ps -ef) then added to exclude lists one by one until meessages about waiting (kernel: eset_rtp(ertp_wait_for_result): wait for scanner reply timeout) had not occured. Quote Link to comment Share on other sites More sharing options...
mskb 0 Posted Wednesday at 03:51 AM Share Posted Wednesday at 03:51 AM @mensch FYI The latest efs version 9.0.461.0 seems to have improved this issue. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.