Answer 1
We try to follow the "tool for the job" philosophy of Unix. It may mean more programs running, but the flexibility you get is usually worth it.
Yes, the machine with the UPS attached will generally have 3
processes (driver, upsd
, upsmon
) running, but this design allows
a much bigger setup. Imagine a data room with a bunch of machines
all drawing power from the same UPS. Only one can be connected by a
serial or USB cable, and the rest of them just run an upsmon
client.
Besides, if upsmon
were rolled into upsd
, upsd
would get even
bigger than it is now. You’d have one less process, but the
RAM consumption would be pretty close to what you have now — but
consumed on each system involved.
See the "Data Room" section in docs/config-notes.txt for more configuration ideas and explanations.
Answer 2
If this really bothers you, roll up your sleeves and use the
sockdebug(8)] code to write a "upsmon" type program that sits on
top of the state sockets. It won’t work over the network, but it means
you don’t need upsd
. It also means only one host can monitor the
UPS.
This is also a good option to consider if you can’t use networked monitoring code for security or safety reasons.
Answer 3
There are plans in the queue… for a long time… to extend upsd
data
server and the NUT clients with ability to use a local Unix socket for the
NUT Networked protocol. This would also allow to forgo the dependency on
TCP/IP stack for communications within one machine.
See the TODO file for more on this and other related topics.