arusconi 5 Posted March 2 Share Posted March 2 Good morning, We have noticed that, once the ESET Bridge service is up and running, some zombie processes start spawning. The entries have a correlation with the output of the "service EsetBridge status" command: ● EsetBridge.service - ESET Bridge Loaded: loaded (/lib/systemd/system/EsetBridge.service; enabled; vendor preset: enabled) Active: active (running) since Thu 2023-03-02 10:52:05 -03; 21min ago Process: 4089 ExecStartPre=/opt/eset/bridge/lib/scripts/before_start.sh (code=exited, status=0/SUCCESS) Main PID: 4093 (Bridge) Tasks: 13 (limit: 981) Memory: 92.1M CGroup: /system.slice/EsetBridge.service ├─4093 /opt/eset/bridge/bin/Bridge ├─4107 nginx: master process /var/opt/eset/bridge/nginx/./sbin/nginx -p /var/opt/eset/bridge/nginx/ ├─4113 nginx: worker process ├─4114 nginx: worker process └─4115 nginx: cache manager process mar 02 10:52:05 esetbridgepjt systemd[1]: Starting ESET Bridge... mar 02 10:52:05 esetbridgepjt systemd[1]: Started ESET Bridge. mar 02 10:52:06 esetbridgepjt Bridge[4093]: CacheSizeMax 5000 mar 02 10:52:06 esetbridgepjt Bridge[4106]: nginx: [warn] the "user" directive makes sense only if the master process runs with super-user privileges, ignored in /var/opt/eset/bridge/ngi> mar 02 10:52:07 esetbridgepjt Bridge[4112]: nginx: [warn] the "user" directive makes sense only if the master process runs with super-user privileges, ignored in /var/opt/eset/bridge/ngi> mar 02 10:57:08 esetbridgepjt Bridge[4306]: nginx: [warn] the "user" directive makes sense only if the master process runs with super-user privileges, ignored in /var/opt/eset/bridge/ngi> mar 02 11:07:28 esetbridgepjt Bridge[4594]: nginx: [warn] the "user" directive makes sense only if the master process runs with super-user privileges, ignored in /var/opt/eset/bridge/ngi> The file /var/opt/eset/bridge/nginx/conf/nginx.conf, which is dynamically generated each time the service is started, starts with an entry : user www-data; That does not match the configuration of the nginx service, whose execution user is "eset-bridge". I would think that this parsing error is causing these problems. Can you tell me if the generation parameters of "nginx.conf" are in a closed code or if this can be changed in some configuration file that is not visible ? I remain pending. Thank you. Best regards. Andres Rusconi Link to comment Share on other sites More sharing options...
ESET Staff IggyPop 19 Posted March 3 ESET Staff Share Posted March 3 Hi @arusconi, There is the nginx.conf.template file from which the actual configuration file is generated. File is located in /var/opt/eset/bridge/nginx/conf dir. Line user www-data; can be commented or removed. The service can then be restarted with sudo systemctl restart EsetBridge.service to check if the issue is still reproducing. Hope it helps, Ingemar Link to comment Share on other sites More sharing options...
arusconi 5 Posted March 3 Author Share Posted March 3 Hello @IggyPop Thank you very much for the reply. After I commented out the line in the template, the error no longer appears in the output of the "service EsetBridge status" command. However, a couple zombie processes are generated when the service is started and a few more continue to appear over time. : ps aux | grep defunct eset-br+ 42189 0.0 0.0 0 0 ? Z 09:28 0:00 [nginx] <defunct> eset-br+ 42195 0.0 0.0 0 0 ? Z 09:28 0:00 [nginx] <defunct> eset-br+ 42350 0.0 0.0 0 0 ? Z 09:33 0:00 [nginx] <defunct> Also, I noticed that the verbosity level of the error_log file established in the nginx.conf.http.server.template file is exaggerated. I understand that this can be adjusted with the $LOG_VERBOSITY environment variable. Where is the value of this environment variable set ? Thank you. Best regards. Link to comment Share on other sites More sharing options...
ESET Staff IggyPop 19 Posted March 6 ESET Staff Share Posted March 6 Hi @arusconi, In regards, to the zombie processes issues has been already fixed internally and it should be released in the next major release of the ESET Bridge. Regarding changing log verbosity, it can be changed from ESET Bridge policy from EP:https://help.eset.com/ebe/1/en-US/index.html?bridge_policy.html If Bridge machine is not managed from EP, it can be done manually from pkgid file: 1) Open /opt/eset/bridge/etc/pkgid file 2) Change "http_proxy_settings_override" to false 3) Change "http_proxy_settings_log_verbosity" to "warn" 4) Restart the ESET Bridge service "http_proxy_settings_override" needs to be set back to true, if you want to manage Bridge from EP at some point. Hope it helps. Ingemar arusconi and Peter Randziak 2 Link to comment Share on other sites More sharing options...
arusconi 5 Posted March 6 Author Share Posted March 6 Hi @IggyPop, Glad to hear that zombies was fixing, hopefully the release will be available soon. I will now set the policy you indicate to avoid touching the default code. Thank you. Best regards. Andrés. Link to comment Share on other sites More sharing options...
Recommended Posts