Unable to start nut-driver after upgrade to Fedora 37

[andrewvillano]

nut-driver.service as well as upsdrvctl is unable to start any of my snmp-ups devices individually or collectively.

These are the errors I'm seeing:

[root@xxxxx run]# upsdrvctl start nutdev7 Network UPS Tools - UPS driver controller 2.8.0 Network UPS Tools - Generic SNMP UPS driver 1.21 (2.8.0) writepid: fopen /var/run/snmp-ups-nutdev7.pid: Permission denied Detected Smart-UPS 2200 on host 10.100.2.49 (mib: apcc 1.6) [nutdev7] Warning: excessive poll failures, limiting error reporting (OID = .1.3.6.1.4.1.318.1.1.1.9.2.3.1.5.1.1.3) [nutdev7] Warning: excessive poll failures, limiting error reporting (OID = .1.3.6.1.4.1.318.1.1.1.9.3.3.1.6.1.1.1)

Fatal error: unable to create listener socket

bind /var/run/snmp-ups-nutdev7 failed: Permission denied

Exiting. Driver failed to start (exit status=1) [root@xxxxx run]#

Thanks in advance.

[jimklimov]

That seems to have been raised just recently on the mailing list and fedora bug tracker, and boils down to wrong packaging (no rights to write into /var/run, there should be a NUT-owned subdirectory):

• https://alioth-lists.debian.net/pipermail/nut-upsuser/2022-November/012997.html
• https://bugzilla.redhat.com/show_bug.cgi?id=2127269

Thanks to @svarshavchik for letting us know.

[jimklimov]

FYI: 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

  • https://github.com/networkupstools/nut/blob/ddbab26b5c595743bf02f9bb71b8d6ba18ce6bb2/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

  • https://github.com/networkupstools/nut/blob/ddbab26b5c595743bf02f9bb71b8d6ba18ce6bb2/clients/upsmon.c#L2369-L2392 -- signals an older (running) instance of itself, using sendsignal(prog) (under PIDPATH) in some cases
  • https://github.com/networkupstools/nut/blob/ddbab26b5c595743bf02f9bb71b8d6ba18ce6bb2/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 https://github.com/networkupstools/nut/blob/ddbab26b5c595743bf02f9bb71b8d6ba18ce6bb2/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

  • https://github.com/networkupstools/nut/blob/ddbab26b5c595743bf02f9bb71b8d6ba18ce6bb2/drivers/main.c#L903 prepares buffer with absolute driver PID file name under altpidpath(), used in https://github.com/networkupstools/nut/blob/ddbab26b5c595743bf02f9bb71b8d6ba18ce6bb2/drivers/main.c#L918 and https://github.com/networkupstools/nut/blob/ddbab26b5c595743bf02f9bb71b8d6ba18ce6bb2/drivers/main.c#L931-L933 to kill off an earlier instance if present, with full-path sendsignalfn().
  • https://github.com/networkupstools/nut/blob/ddbab26b5c595743bf02f9bb71b8d6ba18ce6bb2/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).
  • https://github.com/networkupstools/nut/blob/ddbab26b5c595743bf02f9bb71b8d6ba18ce6bb2/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).
  • https://github.com/networkupstools/nut/blob/ddbab26b5c595743bf02f9bb71b8d6ba18ce6bb2/drivers/main.c#L1145-L1148 calls sendsignal() only for WIN32 usecases (so not relying on PIDPATH for POSIX builds)

• drivers/upsdrvctl.c

  • https://github.com/networkupstools/nut/blob/ddbab26b5c595743bf02f9bb71b8d6ba18ce6bb2/drivers/upsdrvctl.c#L159-L174 tries absolute pidfn variants under altpidpath() to stop_driver() and exits if none of those is present
  • https://github.com/networkupstools/nut/blob/ddbab26b5c595743bf02f9bb71b8d6ba18ce6bb2/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 :

  • https://github.com/networkupstools/nut/blob/ddbab26b5c595743bf02f9bb71b8d6ba18ce6bb2/server/upsd.c#L1600 prepares pidfn under altpidpath()
  • https://github.com/networkupstools/nut/blob/ddbab26b5c595743bf02f9bb71b8d6ba18ce6bb2/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)
  • https://github.com/networkupstools/nut/blob/ddbab26b5c595743bf02f9bb71b8d6ba18ce6bb2/server/upsd.c#L1842-L1853 uses writepid(pidfn) with absolute path (so not relying on PIDPATH)