Don't use upsd.conf in upsmon

[Thermi]

When STATEPATH is configured in upsd.conf, which is currently ignored by upsd, upsmon can't connect to the driver, because it itself honors STATEPATH in upsd.conf (although it's not upsmon's config file), and therefore looks in a different directory than upsd writes the PIDs to.

[jimklimov]

Finally got to take a look at this issue, looks as bogus as it did before - but now I am retrying from scratch to make sense of the wording vs. (expected) reality. Sample "broken use-case" configs would have helped.

The main bogus-looking part is about upsmon interacting with upsd.conf - not only does their code not intersect (well, beside some generic methods in some common/* sources), but also the client can run on a completely different system than the data server, and they only talk TCP/IP to each other (even on localhost), so it would be surprising to see upsmon try to read upsd.* configs. Or directly care about STATEPATH at all.

So trying to find a world where the report makes sense, I think there may be a case of NUT driver daemons and upsd - which do run on the same system and do talk a local socket protocol - placing/finding those socket files in different places. And then if there's a bug here, upsmon (or for that matter, any client like upsc with no config files whatsoever) would have issues reading data (over TCP/IP) from a device driver that its data server does not see.

Drivers do seem to only use a built-in path defined when configure script ran (and since NUT v2.8.0 released in 2022, a common env-var based override for such paths is possible, extensively used in e.g. make check-NIT now), and do seem to lack any *PATH keywords in their ups.conf vocabulary.

For that matter, I suppose if they had a STATEPATH support in ups.conf and it were configured differently from the value in upsd.conf.

@Thermi : does this analysis (namely, the issue being actually between drivers and data server) match what you saw?

[jimklimov]

Something that does make sense to do, as (maybe) highlighted here in a roundabout way, is to allow setting STATEPATH in ups.conf for drivers to use, and for upsd to either accept as fallback or even prefer over the (deprecated then) value in ups.conf. The data server reads from it at least the list of locally drivered devices anyway.

Note that support for envvars in NUT v2.8.x already allows to align different programs about such paths, but this is not something that users of e.g. NUT embedded in appliances might impact (whether they should - may be a separate philosophical discussion).