upsmon child process PID stored in upsmon.pid

[bigon]

Hello,

When using systemd, it complains about the PID stored in the .pid file:

nut-monitor.service: Supervising process XXXX which is not our child. We'll most likely not notice when it exits.

And indeed when looking in upsmon.pid, the PID stored there is the one from the grand-child (unprivileged process) of the process started by init. Shouldn't this be the PID of the direct forked process instead?

[aquette]

2014-04-22 22:39 GMT+02:00 Laurent Bigonville notifications@github.com:

Hello,

Hi Laurent

When using systemd, it complains about the PID stored in the .pid file:

nut-monitor.service: Supervising process XXXX which is not our child. We'll most likely not notice when it exits.

And indeed when looking in upsmon.pid, the PID stored there is the one
from the grand-child of the process started by init. Shouldn't this be the
PID of the direct forked process instead?

look closer and read this FAQ entry:
http://www.networkupstools.org/docs/FAQ.html#_why_are_there_two_copies_of_upsmon_running

that said, is there an "override" mechanism in systemd to avoid this
unnecessary msg?

cheers,
Arnaud

Engineering Linux/Unix Expert - Opensource Solutions Lead - Eaton -
http://opensource.eaton.com
NUT (Network UPS Tools) Project Leader - http://www.networkupstools.org
Debian Developer - http://www.debian.org

Free Software Developer - http://arnaud.quette.fr

Conseiller Municipal - Saint Bernard du Touvet

[bigon]

I'm not sure there is an override.

Is it really a problem to store the pid of the process running as root instead of the unprivileged one?

[bigon]

Apparently the unpriv process complains and continues to run if the privileged process is killed

avr 23 20:31:05 fornost upsmon[9846]: upsmon parent process died - shutdown impossible
avr 23 20:31:05 fornost upsmon[9846]: Parent died - shutdown impossible

[clepple]

Stepping back, what is systemd trying to accomplish by watching the PID? If the intent is to restart upsmon if it is killed, then the right thing might be to use the -D flag to keep the parent process from going into the background. Then systemd can monitor it directly, and the PID file is still available to use for sending SIGHUP to the child to reread the configuration file (per the limitations in the upsmon man page).

[bigon]

Oh indeed we could prevent it to go into the background, this is even advised by systemd developers.

About reloading, we probably need to add the ExecReload= in the systemd service too then

[iva2k]

From the surface looking at it - sounds like there should be two different .pid files for upsmon run as root and upsmon run as nut/unprivileged user. If that's the case, it is a design bug. Should systemd take care of pid of upsmon run as root, and forked unprivileged pid of usbmon run as nut should be taken care of by the forking code?

Is unprivileged pid overwriting root pid and that breaks systemd and / or upsmon operation?

Even if that's not the case, the error messages in syslog do not look comforting and give no confidence that UPS shutdown will work correctly in all circumstances. Sounds like a critical issue. Can someone from NUT team chime in and triage this?

Here's a capture of sudo service nut-client status and ps from Ubuntu 18LTS, latest NUT package:

SERVICES STATUS : CLIENT =======================================================
● nut-monitor.service - Network UPS Tools - power device monitor and shutdown controller
   Loaded: loaded (/lib/systemd/system/nut-monitor.service; enabled; vendor preset: enabled)
   Active: active (running) since Mon 2021-03-01 09:41:38 PST; 7s ago
  Process: 18311 ExecStart=/sbin/upsmon (code=exited, status=0/SUCCESS)
 Main PID: 18313 (upsmon)
    Tasks: 2 (limit: 4915)
   CGroup: /system.slice/nut-monitor.service
           ├─18312 /lib/nut/upsmon
           └─18313 /lib/nut/upsmon

Mar 01 09:41:38 fs1.a.com systemd[1]: Starting Network UPS Tools - power device monitor and shutdown controller...
Mar 01 09:41:38 fs1.a.com upsmon[18311]: fopen /var/run/nut/upsmon.pid: No such file or directory
Mar 01 09:41:38 fs1.a.com upsmon[18311]: UPS: ups2@localhost (master) (power value 1)
Mar 01 09:41:38 fs1.a.com upsmon[18311]: Using power down flag file /etc/killpower
Mar 01 09:41:38 fs1.a.com upsmon[18312]: Startup successful
Mar 01 09:41:38 fs1.a.com systemd[1]: nut-monitor.service: Can't open PID file /var/run/nut/upsmon.pid (yet?) after start: No such file or direc
Mar 01 09:41:38 fs1.a.com systemd[1]: nut-monitor.service: Supervising process 18313 which is not our child. We'll most likely not notice when i
Mar 01 09:41:38 fs1.a.com systemd[1]: Started Network UPS Tools - power device monitor and shutdown controller.

RUNNING PROCESSES ==============================================================
USER       PID %CPU %MEM    VSZ   RSS TT       STAT  STARTED     TIME COMMAND         GROUP      GID
nut      18279  0.0  0.0  21996   456 ?        Ss   09:41:36 00:00:00 usbhid-ups      nut        130
nut      18281  0.0  0.0  38136   364 ?        Ss   09:41:36 00:00:00 upsd            nut        130
root     18312  0.0  0.0  35836  2764 ?        Ss   09:41:37 00:00:00 upsmon          root         0
nut      18313  0.0  0.0  50000  3936 ?        S    09:41:37 00:00:00 upsmon          nut        130

PID FILES ======================================================================
total 16
-rw-r--r-- 1 nut  nut  6 Mar  1 09:41 upsd.pid
-rw-r--r-- 1 root root 6 Mar  1 09:41 upsmon.pid
srw-rw---- 1 nut  nut  0 Mar  1 09:41 usbhid-ups-ups2
-rw-r--r-- 1 nut  nut  6 Mar  1 09:41 usbhid-ups-ups2.pid

[gwaitsi]

The below message re fopen also appears on freebsd variations i.e. freenas/truenas (although nut appears to work and shutdown while all related pids are created)

fopen /var/run/nut/upsmon.pid: No such file or directory
fopen /var/db/nut/upsd.pid No such file or directory

[electrofloat]

So... what is the solution to this issue?

[RJHsiao]

Hi there,
I get same message in my Ubuntu 20.04 LTS server, and no solution found.
Is somebody work on it? Or the solution(s) is/are exist that we can google it with the keyword I don't know?

[jimklimov]

I keep meaning to take a closer look at this, but it keeps drowning in priorities :(

…

On Thu, May 13, 2021, 19:46 RJ Hsiao ***@***.***> wrote: Hi there, I get same message in my Ubuntu 20.04 LTS server, and no solution found. Is somebody work on it? Or the solution(s) is/are exist that we can google it with the keyword I don't know? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#123 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAMPTFGJKKIQA6RWSPPOEXLTNQF53ANCNFSM4AOSH5RQ> .