Skip to content

Technicalities: Work with PID and state file paths

Jim Klimov edited this page Jan 19, 2023 · 1 revision

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

PIDPATH, ALTPIDPATH, STATEPATH

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) *\('

Who does what to PID files?

Clone this wiki locally