[Nut-upsdev] RFC: nut and systemd

[Arnaud Quette]

2011/4/18 Michal Hlavinka <mhlavink at redhat.com>

> Hi,
>

Hi Michal,

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
/etc/sysconfig/ups.
The Debian init script has already started to use it for some versions:
http://git.debian.org/?p=collab-maint/nut.git;a=blob_plain;f=debian/nut.init;hb=HEAD

I would also like to link the below discussion linked to a broader
"packaging improvements" and NPS (NUT Packaging Standard [1]).
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
> /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?

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
> /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
file?).

I'm also seconding Charles' comments.

As told above, the way NUT binaries are currently distributed needs a
revamp.
And I'd like to finally see packagers / distributors seeting around the
table to discuss how to *cleanly* address that.

cheers,
Arnaud
--
[1] http://www.networkupstools.org/docs/packager-guide.chunked/index.html
-- 
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...
URL: <http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20110421/8f202e66/attachment.htm>