<br><div class="gmail_quote">2011/4/18 Michal Hlavinka <span dir="ltr"><<a href="mailto:mhlavink@redhat.com" target="_blank">mhlavink@redhat.com</a>></span><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Hi,<br></blockquote><div><br>Hi Michal,<br><br>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.<br>The Debian init script has already started to use it for some versions:<br>
<a href="http://git.debian.org/?p=collab-maint/nut.git;a=blob_plain;f=debian/nut.init;hb=HEAD" target="_blank">http://git.debian.org/?p=collab-maint/nut.git;a=blob_plain;f=debian/nut.init;hb=HEAD</a><br><br>I would also like to link the below discussion linked to a broader "packaging improvements" and NPS (NUT Packaging Standard [1]).<br>
Thus I've cc'ed Stanislav, who may be interested in (I don't know Suse status on systemd / upstart / ...).<br>I know that some others will be interested in joining the discussion too.<br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
you've probably heard about systemd already. In Fedora 15, it's<br>
used as default instead old SysV init system. While there is some<br>
backward compatibility layer, everything is going to be ported from<br>
/etc/init.d/<something> init scripts to systemd's service files<br>
/lib/systemd/system/<something>.service<br>
<br>
Unfortunately?, systemd is not 1:1 compatible with old init scripts.<br>
Now (at least in Fedora) we have /etc/init.d/ups init script which<br>
starts a)upsdrvctl, upsd, upsmon OR b)just upsmon - that based on<br>
value in /etc/sysconfig/ups. (btw, I've got complaint recently that in<br>
"server" mode it should be possible to start just upsdrvctl and upsd,<br>
without upsmon.)<br></blockquote><div><br>I'm interested in users feedback here (mostly for my own info):<br>are they using PDUs, or only supervising UPSs?<br><br>the MODE in nut.conf is meant to be extended.<br>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).<br>
</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
systemd "prefers" daemon per service/unit file, so it's not possible<br>
to have the same functionality as is with init script.<br></blockquote><div><br>can you please point us some sample scripts for equivalent services?<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
1) systemd does not support:<br>
source /etc/sysconfig/ups<br>
if [ "$SERVER" = yes ]; then<br>
/sbin/upsdrvctl...<br>
/.../upsd<br>
/.../upsmon<br>
else<br>
/.../upsmon<br>
fi<br>
<br>
because it has it's special syntax.<br>
<br>
2) it does not support:<br>
ExecStart=[ "$SERVER" != yes ] || /sbin/upsdrvctl<br>
ExecStart=[ "$SERVER" != yes ] || /.../upsd<br>
ExecStart=/.../upsmon<br>
<br>
because it does not use shell<br>
<br>
3) it "somehow" supports<br>
ExecStart=/usr/libexec/nut/systemd_helper<br>
and put shell script code from #1 there and handle other stuff myself.<br>
<br>
This is somehow ugly solution and despite it is supported, systemd does<br>
not like it (it prefers one not-background-forked daemon per service<br>
file, so it can monitor & other stuff thanks pid of the daemon is pid of<br>
executed process). But - this is only way how to make nut work the<br>
same way as old version. So the question is if it's worth it from long time pov.<br>
<br>
4)The systemd's way:<br>
- 3 service files<br>
- one for upsd and one for upsmon. This means SERVER configuration<br>
from /etc/sysconfig/ups goes away.<br>
- two services configured by user (ups.service/nut.service=upsd, nut-monitor.service=upsmon)<br>
- upsdrvctl as on demand service (started before upsd, stoped after upsd)<br>
<br>
<br>
<br>
So, the question is: 3) or 4) ?<br></blockquote><div><br>as Charles said, the 4th one is the obvious solution to *your* (or *systemd* if you prefer) issue.<br>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?).<br>
<br>I'm also seconding Charles' comments.<br><br>As told above, the way NUT binaries are currently distributed needs a revamp.<br>And I'd like to finally see packagers / distributors seeting around the table to discuss how to *cleanly* address that.<br>
<br>cheers,</div></div>Arnaud<br>--<br clear="all">[1] <a href="http://www.networkupstools.org/docs/packager-guide.chunked/index.html" target="_blank">http://www.networkupstools.org/docs/packager-guide.chunked/index.html</a><br>
-- <br>
Linux / Unix Expert R&D - Eaton - <a href="http://powerquality.eaton.com" target="_blank">http://powerquality.eaton.com</a><br>Network UPS Tools (NUT) Project Leader - <a href="http://www.networkupstools.org/" target="_blank">http://www.networkupstools.org/</a><br>
Debian Developer - <a href="http://www.debian.org" target="_blank">http://www.debian.org</a><br>Free Software Developer - <a href="http://arnaud.quette.free.fr/" target="_blank">http://arnaud.quette.free.fr/</a><br><br>