Vimes24

We raised a support ticket and a workaround fixed our problem for now. The errors stopped with this workaround and the appliance is stable now for 4 days. The variable "DefaultLimitNOFILE" was set to "65535" (Default 1024) in systemd system.conf and user.conf. It can be easily set and rolled back: First create backup-files of the configs: sudo cp /etc/systemd/system.conf /etc/systemd/system.conf.backup sudo cp /etc/systemd/user.conf /etc/systemd/user.conf.backup Set the variable: sudo sed -i "s/.*DefaultLimitNOFILE=.*/DefaultLimitNOFILE=65535 /" /etc/systemd/system.conf sudo sed -i "s/.*DefaultLimitNOFILE=.*/DefaultLimitNOFILE=65535 /" /etc/systemd/user.conf Then reboot the appliance. To roll back this change, just delete config files and rename "*.conf.backup" to "*.conf" and reboot again.

Unfortunately, this problem has become very acute for us now. We are using the ESET Protect On Prem Appliance (Rocky Linux 9.4) and the newest Release ESET PROTECT 11.0.215.0. Rocky OS and all ESET products are patched to the newest version on the appliance. At first the posted workaround worked for us: When the clients reported, that Port 2222 was not reachable we restarted the service of the appliance via console command: systemctl restart eraserver This worked for 1 or 2 days until the service became unresponsible at port 2222 again. But since monday the service at port 2222 "dies" within 5-10 minutes. A restart of the service helps, but only for 5-10 minutes. We are in the process of rolling out new windows-clients and agents (around 50 systems) and at this point the appliance is not usable anymore. Restarting the whole vm or just the service doesn't matter. After 5-10 minutes the service is not reachable at port 2222. Is there a workaround that prevents the service from becoming unresponsive so fast? Or is there an ETA for the new ESET PROTECT version wich fixes this? We searched the trace-log from eraserver, but no warnings or errors were logged.