Aggregating codebase research done in various issues, and linking to some related others, to keep notes organized:

• https://github.com/networkupstools/nut/issues/123
• https://github.com/networkupstools/nut/issues/1299
• https://github.com/networkupstools/nut/issues/1712
• https://github.com/networkupstools/nut/issues/1717
• https://github.com/networkupstools/nut/pull/1719
• https://github.com/networkupstools/nut/issues/1727
• https://github.com/networkupstools/nut/issues/1728

PIDPATH, ALTPIDPATH, STATEPATH

• https://github.com/networkupstools/nut/issues/1712#issuecomment-1327627850

After a bit more digging in current codebase, I can say that NUT unprivileged daemons (drivers and upsd) default to using the ALTPIDPATH in fact -- which in turn defaults to STATEPATH e.g. /var/state/ups since both daemon types exchange pipe files there so may write there, but some package recipes configure it to e.g. /var/run/nut.

This can be seen by code lines preparing a pidfn (usually) with altpidpath() (see common/common.c) in drivers/main.c, drivers/upsdrvctl.c and server/upsd.c.

And then it gets messy in same common/common.c with:

• writepid() which optionally uses PIDPATH (as defined, no ./nut subdir) if file name is not absolute, and with
• sendsignal() which combines PIDPATH (as defined, no ./nut subdir) and the progname to wrap sendsignalfn() (which reads PID from that absolute filename and signals the process in OS-dependent manner).

These latter usages imply that PIDPATH is expected to be writable by nut processes and should not be the root-secured system location (e.g. /var/run directly) unless NUT tools and daemons run as root; can be /tmp however.

I'll post a clean-up PR to clarify this in configure script comments and docs, and "reference" init-scripts and packaging templates which use $PIDPATH/nut to confuse matters more.

Also linking to #123 which creeps out to other big discussions on PID files :)

---

Checking references to the methods mentioned above wit a focus on PIDPATH usage in current state of master branch:

:; git grep -E '(writepid|sendsignal|altpidpath) *\('

• clients/upslog.c

  • github.com/networkupstools/nut@ddbab26b5c/clients/upslog.c (L615-L617) -- writepid(pidfilebase); just before become_user() so expected to be root at that point and may use even a privileged PIDPATH location. The pidfilebase is prog name or set by argument.

• clients/upsmon.c -- the one explicitly documented consumer of configure --with-pidpath

  • github.com/networkupstools/nut@ddbab26b5c/clients/upsmon.c (L2369-L2392) -- signals an older (running) instance of itself, using sendsignal(prog) (under PIDPATH) in some cases
  • github.com/networkupstools/nut@ddbab26b5c/clients/upsmon.c (L2470-L2488) -- writepid(prog) just before become_user() (if running as parent-child pipe and changing privileges at all; saving child PID then), so expected to be root at that point and may use even a privileged PIDPATH location.
  • Note that if upsmon gets split into two processes, the parent part at github.com/networkupstools/nut@ddbab26b5c/clients/upsmon.c (L2034) runs (for non-Windows case) until either the child process exits, or until it sends the message to call shutdowncmd (as root which is the purpose of this split). There is no separate PID file for the parent process.

• drivers/main.c

  • github.com/networkupstools/nut@ddbab26b5c/drivers/main.c (L903) prepares buffer with absolute driver PID file name under altpidpath(), used in github.com/networkupstools/nut@ddbab26b5c/drivers/main.c (L918) and github.com/networkupstools/nut@ddbab26b5c/drivers/main.c (L931-L933) to kill off an earlier instance if present, with full-path sendsignalfn().
  • github.com/networkupstools/nut@ddbab26b5c/drivers/main.c (L949-L953) calls pidfn=buffer; writepid(pidfn); to save the PID value before possibly forking and backgrounding the driver (if backgrounding is enabled).
  • github.com/networkupstools/nut@ddbab26b5c/drivers/main.c (L1145-L1148) calls writepid(pidfn); to save the PID value after possibly forking and backgrounding the driver (if backgrounding is enabled).
  • Note the PID file is neither saved nor queried in foreground mode (e.g. competing driver instances are not killed off either).
  • github.com/networkupstools/nut@ddbab26b5c/drivers/main.c (L1145-L1148) calls sendsignal() only for WIN32 usecases (so not relying on PIDPATH for POSIX builds)

• drivers/upsdrvctl.c

  • github.com/networkupstools/nut@ddbab26b5c/drivers/upsdrvctl.c (L159-L174) tries absolute pidfn variants under altpidpath() to stop_driver() and exits if none of those is present
  • github.com/networkupstools/nut@ddbab26b5c/drivers/upsdrvctl.c (L185-L224) further in stop_driver() uses the absolutely-pathed sendsignalfn() in POSIX use-cases

• scripts/Windows/wininit.c

  • two WIN32 usecases of sendsignal() (so not relying on PIDPATH for POSIX builds)

• server/upsd.c :

  • github.com/networkupstools/nut@ddbab26b5c/server/upsd.c (L1600) prepares pidfn under altpidpath()
  • github.com/networkupstools/nut@ddbab26b5c/server/upsd.c (L1686-L1697) makes use of sendsignal*() variants, with sendsignal() specifically called only for WIN32 usecases (so not relying on PIDPATH for POSIX builds)
  • github.com/networkupstools/nut@ddbab26b5c/server/upsd.c (L1842-L1853) uses writepid(pidfn) with absolute path (so not relying on PIDPATH)

Who does what to PID files?

• https://github.com/networkupstools/nut/issues/1728#issuecomment-1335371798
• https://github.com/networkupstools/nut/pull/1724