upsd.pid/upsmon.pid are important for live config reload (systemd might do without it?)

[jimklimov]

Currently our daemons allow to run their binary in a way that they send a signal to earlier launched copy of the process, using the saved PID file, and so tell it to reload configuration.

With recent changes aimed at avoiding daemon backgrounding (particularly in systemd wraps), we are losing reasons to keep up the PID file manipulation in certain usage scenarios. Need to investigate redefining systemd unit "ExecReload" lines:

• is there equivalent signal-sending right away?
• can we use the $MAINPID (IIRC the name) and extend the daemon CLI args in a way that we would tell the program which process it should communicate with (same data it would get from a PID file, but without a file)

See also #123

[ebenostby]

Apologies for hijacking this thread with a question - though in upsd you can override directory for pid files, AFAIK with upsmon it's hardwired to PIDPATH (/var/run) and can't be overridden at runtime. It could be changed at build time. To prevent problems with cruft left in the pidfile I've symlinked /var/run to /tmp so it gets cleaned at reboot. My question is: should this be configurable for upsmon? Shouldn't it be in /tmp?
Thanks for your thoughts.

[jimklimov]

I'm currently not with a computer so can't check directly, but with modern codebase I think the "configure-hardcoded" path is considered after optional envvars like (IIRC) NUT_ALTPIDPATH - better search in code for the names. There are several vars involved, in my tests I often dealt with NUT_STATEPATH (driver socket files) and NUT_CONFPATH (config files) to run custom builds of drivers and server as unprivileged user and not barge into stable setup.

Other than that, OS is a large part of the question here :) For example, on recent decade+ of Linux, /var/run is a symlink to /run which is a tmpfs; distros vary about volatile or persistent /tmp. On this millenium's Solaris/illumos both /tmp and /var/run are tmpfs (swap).

Even if looking into code finds that paths are "hardcoded" (should be at configure time then), and you're limited into using packaged builds, then you should bring it up with your OS packagers so they "hardcode" a volatile path for pid files. And PRs to NUT to locate and improve missing envvar customization would also be welcome :)

On Fri, Apr 1, 2022, 04:44 ebenostby @.***> wrote:

Apologies for hijacking this thread with a question - though in upsd you can override directory for pid files, AFAIK with upsmon it's hardwired to PIDPATH (/var/run) and can't be overridden at runtime. It could be changed at build time. To prevent problems with cruft left in the pidfile I've symlinked /var/run to /tmp so it gets cleaned at reboot. My question is: should this be configurable for upsmon? Shouldn't it be in /tmp? Thanks for your thoughts.

— Reply to this email directly, view it on GitHub https://github.com/networkupstools/nut/issues/1299#issuecomment-1085354417, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAMPTFDJOAJO6CBWYAZKXULVCZPHXANCNFSM5ORC7SSQ . You are receiving this because you authored the thread.Message ID: @.***>

[ebenostby]

Good advice. Many thanks.