Add a '-n no-conf' option to upsdrvctl / upsd / upsmon to avoid failure when not yet configured

[aquette]

nut.conf was in charge of telling init sysV script if NUT was to be started, and which component(s).
With newer init system, such as systemd, nut.conf is useless and all installed components are tried to be started. This results in failures, at least at initial installation.
By adding a '-f force-no-conf' option, we avoid returrning EXIT_FAILURE if no device in configured in ups.conf nor in upsmon.conf.
We may also consider broadening the scope to all configuration.
i.e., if no configuration file is found, don't EXIT_FAILURE.
However, note that other errors are not covered.
@bigon , @clepple : any comment?

References:

• https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=747863

[clepple]

Since you mention systemd, do we want to have another standard option for "don't background"? (This would also be used for launchd on OS X).

At the moment, we can use "-D" but that causes unnecessary logging that will only be discarded.

I mention this because "-f" makes sense for a "foreground" option. We could also use "-F". I'm not partial to either one.

However, "-f force-no-conf" seems odd: sort of a hybrid --long-option but without the opportunity to use the shortest possible prefix. Not suggesting that we move to getopt_long(), just that this could probably be done with a single flag character.

[aquette]

you got a point @clepple ;)
I was more on the '-n no-conf' at first. That leaves you the room for '-f' which makes sense in lower-case.
So what would exactly mean '-f' beside from not going background (i.e. what about fd and init?)

[clepple]

So what would exactly mean '-f' beside from not going background (i.e. what about fd and init?)

fd: do you mean closing stdin/stdout/stderr? Not sure what is considered best practices for systemd. launchd will let you log if needed, so it doesn't matter there.

Not sure what you mean by "init".=

[aquette]

@clepple: I meant attaching to init, pid 1, systemd, launchd, ...

[clepple]

If a process doesn't fork and background, then it is still attached to the parent that started it.

This might be veering off into another thread, but do we have a list of things that we need to change to make NUT behave better with systemd? If not, is there a checklist from the systemd folks? I admit that I have not looked at this much.

[aquette]

@cleppe : just to clarify, since you've probably updated the comment.
this new option is really a single char. one, i.e. '-n'. The long keywords attached is just a disabiguation, but doesn't appear elsewhere for users.

[aquette]

question on upsd behavior when no device is configured ( @clepple esp.):
do we want to exit(EXIT_SUCCESS) or to continue and server no device?
commit c0c1262 implements the 2nd behavior, but the 1rst one may be more suitable...

[clepple]

Again, I don't have much direct experience with systemd, but applying what I know about launchd: if upsd stays running, it can listen for a reconfigure signal. If it exits, you have to specify additional configuration options to keep the init replacement from trying to continuously respawn the daemon.

[aquette]

It works almost fine: upsdrvctl and upsd are good.
however, for upsmon, the PIDFile directive in nut-monitor.service make it fail.

With PIDFile:

systemctl status nut-monitor.service

nut-monitor.service - Network UPS Tools - power device monitor and shutdown controller
Loaded: loaded (/lib/systemd/system/nut-monitor.service; enabled)
Active: failed (Result: resources) since dim. 2014-09-28 19:07:18 CEST; 1s ago
Process: 17095 ExecStart=/sbin/upsmon -n (code=exited, status=0/SUCCESS)
Main PID: 677 (code=exited, status=0/SUCCESS)

sept. 28 19:07:18 arno-zbook15 upsmon[17095]: Using power down flag file /etc/killpower
sept. 28 19:07:18 arno-zbook15 upsmon[17095]: Network UPS Tools upsmon 2.7.2-signed-104-gc0c1262
sept. 28 19:07:18 arno-zbook15 upsmon[17095]: Warning: no MONITOR line defined!
sept. 28 19:07:18 arno-zbook15 upsmon[17095]: Warning: insufficient power configured!
sept. 28 19:07:18 arno-zbook15 upsmon[17095]: Sum of power values........: 0
sept. 28 19:07:18 arno-zbook15 upsmon[17095]: Minimum value (MINSUPPLIES): 1
sept. 28 19:07:18 arno-zbook15 upsmon[17095]: Edit your upsmon.conf and change the values.
sept. 28 19:07:18 arno-zbook15 systemd[1]: PID file /var/run/nut/upsmon.pid not readable (yet?) after start.
sept. 28 19:07:18 arno-zbook15 systemd[1]: Failed to start Network UPS Tools - power device monitor and shutdown controller.
sept. 28 19:07:18 arno-zbook15 systemd[1]: Unit nut-monitor.service entered failed state.

Without PIDFile (after calling 'systemctl start nut-monitor.service'):

systemctl status nut-monitor.service

nut-monitor.service - Network UPS Tools - power device monitor and shutdown controller
Loaded: loaded (/lib/systemd/system/nut-monitor.service; enabled)
Active: inactive (dead) since dim. 2014-09-28 19:08:13 CEST; 3s ago
Process: 17112 ExecStart=/sbin/upsmon -n (code=exited, status=0/SUCCESS)
Main PID: 677 (code=exited, status=0/SUCCESS)

sept. 28 19:08:13 arno-zbook15 upsmon[17112]: fopen /var/run/nut/upsmon.pid: No such file or directory
sept. 28 19:08:13 arno-zbook15 upsmon[17112]: Using power down flag file /etc/killpower
sept. 28 19:08:13 arno-zbook15 upsmon[17112]: Network UPS Tools upsmon 2.7.2-signed-104-gc0c1262
sept. 28 19:08:13 arno-zbook15 upsmon[17112]: Warning: no MONITOR line defined!
sept. 28 19:08:13 arno-zbook15 upsmon[17112]: Warning: insufficient power configured!
sept. 28 19:08:13 arno-zbook15 upsmon[17112]: Sum of power values........: 0
sept. 28 19:08:13 arno-zbook15 upsmon[17112]: Minimum value (MINSUPPLIES): 1
sept. 28 19:08:13 arno-zbook15 upsmon[17112]: Edit your upsmon.conf and change the values.
sept. 28 19:08:13 arno-zbook15 systemd[1]: Started Network UPS Tools - power device monitor and shutdown controller.

@bigon : is PIDFile really useful? I know it tracks the PID of the upsmon instance that actually does the shutdown. But beyond from 'eye candy', is there any other impact?

[aquette]

@bigon: any comment?
I also have to check the Condition* available, as pointed by Martin (Pitt)

[bigon]

Oh hey,

The preferred way to start daemon with systemd is not to fork them and keep them in foreground. In that case no PIDfile is needed.