> 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.
afaik this is not compatible to "4)" For this, upsmon must me separated, so you'd get something like /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 ============== [Unit] Description=Self Monitoring and Reporting Technology (SMART) Daemon After=syslog.target [Service] EnvironmentFile=/etc/sysconfig/smartmontools ExecStart=/usr/sbin/smartd -n $smartd_opts [Install] WantedBy=multi-user.target ================================== it can read basic shell-like variables (/etc/sysconfig/smartmontools) and pass them to command line. It can't contain any conditional in service file > > 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?). 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 upsd service. _______________________________________________ Nut-upsdev mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
