upsd uses PID files before looking at upsd.conf and before chrooting

[jimklimov]

https://alioth-lists.debian.net/pipermail/nut-upsuser/2022-December/013026.html

... Just for grins, I edited /etc/ups/upsd.conf to uncomment the STATEPATH
line. I set it to /run/nut. When I ran upsd -DD again, it was still
looking at /var/run. However! It successfully connected to the
cyberpower device. Upsc returns good information.

# upsd -DD
> Network UPS Tools upsd 2.8.0
>     0.000000     fopen /var/run/upsd.pid: No such file or directory
>     0.000037     Could not find PID file '/var/run/upsd.pid' to see if
> previous upsd instance is already running!
>
>     0.000271     [D1] debug level is '2'
>     0.000357     listening on ::1 port 3493
>     0.000395     listening on 127.0.0.1 port 3493
>     0.001550     Connected to UPS [cyberpower]: usbhid-ups-cyberpower

Curious finding up there. I think this is due to load_upsdconf(0); being at https://github.com/networkupstools/nut/blob/master/server/upsd.c#L1776 -- so being after the initial signal-probing for competitors (or sending a command to a running daemon), so using built-in PID/STATE paths, and notably that probing happens before the optional chrooting (and PID file is later recorded relative to the chroot).

For that initial probing, it would honor the NUT_ALTPIDPATH envvar (although still disregarding "relative to chroot" part if used), but not yet the know config file contents.

So it is messed up somewhat.

FWIW, last week I tried to track down current usage of various PATHs in the sources, see #1712 (comment) if interested :)

CC @aquette @clepple : is this a low-hanging fruit (to smartly reshuffle a few lines), or do I miss something in the bigger picture and historic considerations?

[jimklimov]

Looking at

nut/clients/upsmon.c

Line 2430 in 2f01d9a

loadconfig();

the upsmon program suffers similarly - it sends signals first (which may rely on path to PID file in some scenarios) and calls loadconfig() after that. Does not chroot at all though.

[jimklimov]

Drivers do not seem to have this problem - they call upsdrv_makevartable(); before processing CLI args etc:

• nut/drivers/main.c

  Line 731 in e28acf8

  upsdrv_makevartable();

They chroot and become_user at

nut/drivers/main.c

Lines 885 to 888 in e28acf8

	if (chroot_path)
	chroot_start(chroot_path);
	become_user(new_uid);

just before looking at PID files and signaling the running instance if present (to kill that off so the new driver runs).

Arguably there may be a problem that "chroot" happens after we read_upsconf() for -a UPSNAME argument handling.

Historically this part was problematic if the PID file was not available and the running sibling could not be located and killed off, e.g.:

• Driver restart fails to kill older sibling and never retries #1423
• SIGKILL an earlier driver instance if SIGTERM does not cut it [part of #1423 fix] #1424
• Investigate pipe-file protocol (driver-upsd) use to kill old driver instances #1664

[jimklimov]

Looking at chroot in all these contexts, I wonder (need to read up history docs) if that tree should have NUT config files, or those are intentionally held in the "host" OS and are not abusable in the chroot?..

In the latter case, reload should not be available... right? Or let people do wild setups with same, different or missing configs between host and chroot trees?

Likewise, should (by design) paths to PID and/or state (pipe) files be relative to the chroot jail or to the host system?.. (this is a different question from reading config files "too late")

[jimklimov]

Finally, regarding config file impact on PID-related paths, this seems to be constrained to upsd.conf and STATEPATH (which is the fallback if ALTPIDPATH is not set). Other daemons use only the built-in strings or envvars if available. This yields a discrepancy that this path may not be configured for drivers (other than via envvars).