Jump to content

EFS for Linux issue - eset_rtp(ertp_wait_for_reply) - Ubuntu 21.04


Recommended Posts

Hi Peter,

Does this help? On reboot some ESET messages.

Missing part are timestamps on the left, no useful help there, I think.

About LesRMed answer: software installs that part around with the FS access may leave some "scars" behind. So, superhot's system was normal, installed ESET, got b slower, remove and didn't help: so maybe there is also a problem on uninstalling it too. Are you going though the same problem as us? If not, you probably can't simulate the problem locally to understand the problem or help.

I've mentioned it once and would like to mention it again, as there are other softwares that are incompatible with it: I use Nvidia's proprietary driver for X. Anybody who is having this issue is using the Nvidia proprietary driver too? I would not be surprised that this is the root of all this pain. 

Cheers, Peter and Superhot.

IMG_20210810_235621.jpg

Edited by ph4ckvv3r
Link to comment
Share on other sites

LesRMed and Peter,

Yesterday I couidn't even do screenshots anymore. I've captured, and when trying to paste images were broken and machine started to be really slow again. I ran htop and see my cores at very low usages (2-5%) and plenty of RAM - I have 64GB so it's quite hard to get it full. 

image.thumb.png.617a24c31785f53ea3e74266f1960b1a.png

Today I've noticed slowness twice, and it was on the service restart I've put in cron (which, tbh, wasn't causing problems before). Slowness happened today at 11h15 and 12h00. The first one I had to reboot as I was doing a call that exact moment, but the second one at 12h00 I waited. 2 minutes. Machine comes back to normal. So, I've decided to comment the crontab restart in the service. And I will start to check if the slowness is only on boot as others have reported. in my case it happens "sometimes" on boot, but it had stopped for a while.

Well, there you have date and time (13/08/2021, 11h15 and 12h00-12h02) AND MY LOGS! Ehhhhh! 😄 Maybe this will solve the mistery... 

Unmasked! Every Scooby-Doo! Where Are You? Villain Revealed in Under 4  Minutes - YouTube

BTW: I can't attach the .tar.gz from logs here. Hahahaha, it's funny, file has been generated by your tool.

Here is the zipped version with my logs. Hope you can find something there.

Cheers,

Pablo 

 

 

eea_logs.zip

Edited by ph4ckvv3r
Link to comment
Share on other sites

Hi all,

I've found this checking my syslog. The first part seems a bit problematic, other 2 images seems just RTP hooking to the syscalls to do RTP. I've noticed that the Gnome Tracker is quite intensive on file scanning... Shouldn't be a problem but maybe at some point it could have a conflict on file access? Well, leaving this here, not sure this helps.

 

image.thumb.png.dbd92cdc08e453d54c5bde312ac51849.png image.png.a24f55db3b1ab5bfeb1c225e8cdd37ef.png

image.png.d24ef72204f58d8733ef28558919466d.png

Edited by ph4ckvv3r
Link to comment
Share on other sites

Hi, seems I was abandoned but I'm reporting another thing now...

I've just upgraded my kernel to get 5.13, as I'm stuck on 5.11 with Ubuntu 21.04. And, I'm repeating the whole setup process again and for the first time I get this message of missing packages here

 

image.png.a40b15a110f4d52c0f1c5e888fb29185.png

So, now I will try to sort this out and see what happens.

Link to comment
Share on other sites

"apt fix broken install" did the trick, but the my machine is still really slow when RTP is on.

Question: is anybody else out there using NVidia RTX 30 series with multiple displays? I have 3 screens here and I only notice the slowness when using X. If I boot to text, I'm ok. 

Link to comment
Share on other sites

Wel, another thing I will try here:

IntelliJ just warned about low values for inotify.max_user_watches.

image.png.462c1c7773cff159289c2e57245b46fd.png

Changing it now to 

fs.inotify.max_user_watches=5242881
fs.inotify.max_user_instances=1024
fs.inotify.max_queued_events=32768

I still had one episode of slowness here. But most of the time machine is super usable. Let's hope those limits increased fix the problem.

Link to comment
Share on other sites

Hi guys,

So after ALL those changes, I still had random moments of slowness which were solved by restart eea service.

Then I thought: is this antivirus scanning the filesystem? So, does this mean that write and read from network device is being scanned too? Is it also scanning /proc?! 

I've decided to add /dev and /proc to the "ignored" paths (+ /var/lib/docker). If I notice that I don't have anymore hangs on Monday morning boots after machine down for 2 days, I will let you know.

Link to comment
Share on other sites

  • 2 weeks later...

Hi, one last thing added to the exceptions list: /opt/eset.

 

image.png.0b2abd7518cbc15f34d08698e571120e.png

I was having this error, so I thought it would be better not to give access to my user to the antivirus folder and at the same time add it to the exclusions folder.

I must report that I have no more slowness here.

image.thumb.png.20868c413825696ddf8d3bc0be56974f.png 

Link to comment
Share on other sites

Not to hijack the thread, but we also ran into this same issue last week on Red Hat 6, 7, and 8 on both available versions of ESET Server Security in the 8.1 branch (8.1.565.0 & 8.1.685.0).  The older ESET File Security 8.0.375.0 seems to be unaffected. 

At the time, we had no choice but to immediately stop the EFS daemon and subsequently uninstall it to restore our services.  So, I don't have a lot of troubleshooting information from during the event.  However, since we would like to eventually update the software, I would be happy to provide additional information or participate in testing to help figure things out.

Link to comment
Share on other sites

  • ESET Staff

Hi zhopkins,

so you are still experiencing issues with the latest Server Security release (8.1.685.0)? We have identified issues with our real-time kernel module and they are fixed in this release. Could you please somehow help me to replicate it? what kind of software are you using on these machines, if it's not a secret? maybe what file-systems are you using there, if network shares are connected? Also what about EDTD? are you using this security feature?

One more thing? Your machines started to slow down or became fully unresponsive?

Thanks,
Peter  

Link to comment
Share on other sites

Peter,

Some examples for you -

  • RHEL6 / Oracle / EXT4 local disks / CIFS remote shares
  • RHEL7 / Oracle / EXT4 local disks / No remote shares
  • RHEL7 / Icinga2 / EXT4 local disks / No remote shares
  • RHEL8 / DNSMasq / XFS local disks / No remote shares

I'm fairly certain that we are not using EDTD, since that is a separately licensed product?  It does not appear in the "Products & Licenses" section for the machines in the ESET PROTECT console.

Overall, I believe most of the servers (some physical, most virtual) managed to get through with only minor slowdowns, however, the server that runs our Icinga monitoring became extremely unresponsive, to the point where I was unable to login via SSH or the console (even with root credentials).  I had to push a task through the ESET Management Agent to stop the EFS daemon before I could log in.

Link to comment
Share on other sites

  • 2 weeks later...
  • ESET Staff

Hi Zhopkins,

I have tried to replicate your issues, but without any success. I have prepared machines with configurations as you pointed in previous comment, but it looks like, I don't have enough events for RTP. From my previous experience, I would try to exclude DB files from scanning. Sometimes this files become really huge and there are also to much events, which results into slowdowns.   

Regards,

Peter 

Link to comment
Share on other sites

Peter,

As it happens, we do already have Performance Exclusions in place for our Oracle database and Icinga.  Additionally, when I first saw the issue on those servers, the first thing I did was to modify the ESET policy to disable scanning on file open (leaving only on file creation), but that did not seem to help.

I might not be able to get to it this week, but I will spin up a server with the newer version of ESET so I can do some more direct testing for you all to try and figure this out.

Thank you,

--Zachary

Link to comment
Share on other sites

  • 2 weeks later...

Peter,

I was able to spin up a fresh VM and do some additional testing.  ESET Server Security v8.1.565.0 immediately starts logging eset_rtp errors in the main "messages" log file (even on a blank VM with just our base OS install).  The slightly newer version, v8.1.685.0, does not seem to cause these error messages.

With the latest version (8.1.685.0), I have noticed a strange behavior with the 'less' command, and I am trying to do some additional investigating to see if that issue is still related to the issue in this thread.  The less command (literally "less /var/log/messages") triggers a "Waiting for data... (interrupt to abort)" message on nearly every open of the log file.  This behavior is abnormal in our environment, so I want to be sure that the newer version of the antivirus is still not causing issues or delays when opening files.

Link to comment
Share on other sites

  • ESET Staff

Hi Zachary,

thanks for info, please let me know about your findings. I have seen this message before also on machines without our product, but logs there were really huge and it disappears after few seconds. So when our product is stopped, it works correctly? 

Thanks,

Peter 

 

Link to comment
Share on other sites

Yes, Peter.  In my initial testing, trying to read the main log files (/var/log/messages and /var/log/secure) using the "less" command, they displayed the "Waiting for data... (interrupt to abort)".  I saw this behavior when I opened the log files 5 times in a row.  As soon as the efs daemon was stopped, I was able to run the same command, with no such message.

--Zachary

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...