2011/4/18 Michal Hlavinka <[email protected]> > 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/
_______________________________________________ Nut-upsdev mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
