[Nut-upsdev] RFC: nut and systemd
mhlavink at redhat.com
Thu Apr 21 08:49:29 UTC 2011
> as a first note, I just want to remember you the existance of
> $(sysconfdir)/nut.conf, to replace both Debian's /etc/default/nut and RedHat
afaik this is not compatible to "4)" For this, upsmon must me separated, so you'd get
/etc/init.d/nut (for upsdrvctl and upsd)
/etc/init.d/nut-monitor (for upsmon)
> 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
> > /lib/systemd/system/<something>.service
> > 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,
> > without upsmon.)
> I'm interested in users feedback here (mostly for my own info):
> are they using PDUs, or only supervising UPSs?
there is user experience with systemd and any ups daemon,
afaik Fedora has only 2 of them (nut and apcupsd). And it'll be my task to
modify apcupsd to use systemd.
> the MODE in nut.conf is meant to be extended.
> I once evoked a "upower" mode (drivers started by udev) and a "manual" one
> (started by whatever other mechanism that only need pieces of NUT).
> > systemd "prefers" daemon per service/unit file, so it's not possible
> > to have the same functionality as is with init script.
> can you please point us some sample scripts for equivalent services?
a)equivalent services=ups daemon, there is no such example (yet). nut
was chosen to be the first one
b)equivalent services=more daemons started by one init script - I'm not
aware of anything like that. Usually such services have one master process
reading configuration and starting what is needed.
c)example of systemd service file:
============== smartd.service ==============
Description=Self Monitoring and Reporting Technology (SMART) Daemon
ExecStart=/usr/sbin/smartd -n $smartd_opts
it can read basic shell-like variables (/etc/sysconfig/smartmontools)
and pass them to command line. It can't contain any conditional in
> > 1) systemd does not support:
> > source /etc/sysconfig/ups
> > if [ "$SERVER" = yes ]; then
> > /sbin/upsdrvctl...
> > /.../upsd
> > /.../upsmon
> > else
> > /.../upsmon
> > fi
> > because it has it's special syntax.
> > 2) it does not support:
> > ExecStart=[ "$SERVER" != yes ] || /sbin/upsdrvctl
> > ExecStart=[ "$SERVER" != yes ] || /.../upsd
> > ExecStart=/.../upsmon
> > because it does not use shell
> > 3) it "somehow" supports
> > ExecStart=/usr/libexec/nut/systemd_helper
> > 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) ?
> as Charles said, the 4th one is the obvious solution to *your* (or *systemd*
> if you prefer) issue.
> I'd like to see an example POC implementation of this, since details are
> still unclear to me (ex: what means an "on demand servive"? no .service
For example dovecot (imap server) can be started on demand. systemd listens
on port 143 and when there is incomming connection, it starts dovecot. On-demand
service needs service file.
There is more on-demand events (device, another service,....)
Simple on-demand (required by different service file) should be suitable for upsdrvctl.
1) Create simplified nut-device.service (no [install] section...)
2) Create upsd service and add Requires=nut-device.service After=nut-device.service
so when you start upsd by hand or during boot process it starts upsdrvctl firts. If you
add StopWhenUnneeded=yes to nut-device.service it stops upsdrvctl after stopping
More information about the Nut-upsdev