[Nut-upsdev] RFC: nut and systemd
mhlavink at redhat.com
Mon Apr 18 14:36:45 UTC 2011
you've probably heard about systemd already. In Fedora 15, it's
used as default instead old SysV init system. While there is some
backward compatibility layer, everything is going to be ported from
/etc/init.d/<something> init scripts to systemd's service files
Unfortunately?, systemd is not 1:1 compatible with old init scripts.
Now (at least in Fedora) we have /etc/init.d/ups init script which
starts a)upsdrvctl, upsd, upsmon OR b)just upsmon - that based on
value in /etc/sysconfig/ups. (btw, I've got complaint recently that in
"server" mode it should be possible to start just upsdrvctl and upsd,
systemd "prefers" daemon per service/unit file, so it's not possible
to have the same functionality as is with init script.
1) systemd does not support:
if [ "$SERVER" = yes ]; then
because it has it's special syntax.
2) it does not support:
ExecStart=[ "$SERVER" != yes ] || /sbin/upsdrvctl
ExecStart=[ "$SERVER" != yes ] || /.../upsd
because it does not use shell
3) it "somehow" supports
and put shell script code from #1 there and handle other stuff myself.
This is somehow ugly solution and despite it is supported, systemd does
not like it (it prefers one not-background-forked daemon per service
file, so it can monitor & other stuff thanks pid of the daemon is pid of
executed process). But - this is only way how to make nut work the
same way as old version. So the question is if it's worth it from long time pov.
4)The systemd's way:
- 3 service files
- one for upsd and one for upsmon. This means SERVER configuration
from /etc/sysconfig/ups goes away.
- two services configured by user (ups.service/nut.service=upsd, nut-monitor.service=upsmon)
- upsdrvctl as on demand service (started before upsd, stoped after upsd)
So, the question is: 3) or 4) ?
More information about the Nut-upsdev