Question: Incompatibility with OSTree linux systems. Configure new pid path?

[oglok]

I'm using an OSTree based system (Fedora), where /run is read-only as many other paths in the filesystem. When I run the nut-server service I get the following:

upsd -FF
Network UPS Tools upsd 2.8.2.1
Could not find PID file '/run/nut/upsd.pid' to see if previous upsd instance is already running or not!
Can't open /etc/ups/upsd.conf: Permission denied

Is there a way to change the path like specified here? https://networkupstools.org/docs/user-manual.chunked/aphs07.html

Thanks!

[jimklimov]

Cheers, thanks for the report even if this sounds plain wrong.

The /run location should be a mountpoint for a tmpfs based filesystem which a lot of things in the system rely on casually. So either the distribution took deliberate steps to be very different from others (not too uncommon, NixOS or Android come to mind - but unlikely for a "Fedora based" distro), or something is broken (the tmpfs did not get mounted?), or, most likely, you are running NUT programs as a plain user who just does not have permissions to write into a root-owned location like /run (the Can't open /etc/ups/upsd.conf: Permission denied also points to that probable cause). Another possibility is that specifically /run/nut was not created (or not chown'ed properly), and the daemons which need it can not access it (at all, or after dropping privileges).

Two things come to mind:

• Older reported issues like Service nut-server / upsd not starting automatically on CentOS / RockyLinux #2721 or Unable to start nut-driver after upgrade to Fedora 37 #1712 or Support for Tripplite SUINT1500LCD2U #2808 (comment) that should have got solved by Introduce service wrapping for upslog client daemon, and nut-systemd.preset file #2746 (part of upcoming NUT v2.8.3) - primarily about NUT services not starting because the packages did not enable the NUT target units for systemd.
• An absent /run/nut may be due to NUT systemd units in the package, or system boot-up overall, not applying the systemd-tmpfiles entries from /usr/lib/tmpfiles.d/nut-common-tmpfiles.conf or similar. This was reported for Ubuntu/Debian packages, but I don't remember seeing as a Fedora/RHEL/... problem yet.

[jimklimov]

As for the other part of your question, "Is there a way to change the path like specified here" - check the docs/sources (notably tests/NIT/nit.sh for practical example) about environment variables like NUT_CONFPATH, NUT_STATEPATH and NUT_ALTPIDPATH, which can tweak the programs' behavior and override the built-in values at run-time.

If you are using a custom build of NUT, check the tons of configure script options to tune it for your system.

More strictly speaking, if you did get NUT via packaging and use it properly (via services, daemons started initially as root, and all) and then it does not work right - this is a distro/packaging problem (so the package authors should tweak those configure script options to fit the R/W locations of the system).

One more location to note is the POWERDOWNFLAG location in upsmon.conf, which should be in a writeable location that is still mounted (even if read-only) when your system goes down. The flag tells late-shutdown integration scripts like nutshutdown hook for systemd that the UPS should be commanded to turn off because the system goes down due to an outage (so the driver programs should also be visible and runnable at that point). For a bit more context on this, see docs and #2836 with regard to largely-read-only systems in particular (thanks for the indirect reminder to write that down).