[Nut-upsdev] RFC: nut and systemd
aquette.dev at gmail.com
Thu Apr 21 07:47:20 UTC 2011
2011/4/18 Michal Hlavinka <mhlavink at redhat.com>
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
The Debian init script has already started to use it for some versions:
I would also like to link the below discussion linked to a broader
"packaging improvements" and NPS (NUT Packaging Standard ).
Thus I've cc'ed Stanislav, who may be interested in (I don't know Suse
status on systemd / upstart / ...).
I know that some others will be interested in joining the discussion too.
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,
> without upsmon.)
I'm interested in users feedback here (mostly for my own info):
are they using PDUs, or only supervising UPSs?
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?
> 1) systemd does not support:
> source /etc/sysconfig/ups
> 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
> 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,
> - 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
I'm also seconding Charles' comments.
As told above, the way NUT binaries are currently distributed needs a
And I'd like to finally see packagers / distributors seeting around the
table to discuss how to *cleanly* address that.
Linux / Unix Expert R&D - Eaton - http://powerquality.eaton.com
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.free.fr/
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Nut-upsdev