On 20/08/2015 08:57, Colin Booth wrote:
> When running s6-rc -v2 change $bundle, the s6rc-fdholder "pre addition
> of notification-fd" message has some garbage characters in it:
> s6-svc: warning: /run/s6/rc/scandir/s6rc-fdholderà¯'þpre addition of
> notification-fd
> s6-svc: warning: /run/s6/rc/scandir/s6rc-fdholder/notification-fdpost
> addition of notification-fd
Looks like a missing/wrong string terminator. Thanks for the report,
I'll look for it.
> As for the best practices question. What's the right way to fake
> service notification for daemons that don't support it?
Just don't have a notification-fd file. s6-rc will assume your daemon
is ready as soon as the run script is started. It may spam you with a
warning on high verbosity levels, but that's it. :)
> fdmove 1 3
> foreground { s6-echo "" }
> /lib/systemd/systemd-udevd
Yeah, it really depends on what you want to do with stdout. I think
the cleanest way to write the the above would be something like
if { fdmove 1 3 s6-echo "" }
fdclose 3
/lib/systemd/systemd-udevd
> Now, I'm pretty sure that the cleanest method would be to break it up
> into two atomics:
> oneshot udev-init - runs `udev start' and `udevadm control --exit'
> longrun udev-svc - normal run script handling the maintenance of systemd-udevd
Yes, that's probably the best way to do it.
> The general question though is: what's the best way to handle
> readyness notification on services that run a prep script before
> starting the daemon proper. Assuming daemon availability is relatively
> instant, is foregrounding your initialization script and then moving
> the notification fd onto stdout right before sending a blank message
> the best method?
If your daemon doesn't support readiness notification, I'd generally
advise not to pretend it does: even if daemon availability is fast,
the scheduler can always screw you. So yes, if at all possible, having
the init in a oneshot and the daemon in a longrun depending on the
init oneshot is the best way to go, without declaring a notification-fd
for the longrun. If it's not possible, foregrounding the init, then
sending a blank notification message, then execing the daemon, is
probably the least ugly way to proceed.
I'm surprised that systemd-udevd doesn't provide notification: that's
one of the least bad reasons for daemons to integrate with systemd.
Doesn't it use sd_notify() ?
> Also, it'll be nice to have s6-rc-update, I've been rebooting...
> a lot.
No need to reboot:
s6-rc -da change
for i in `ls -1 $live/servicedirs` ; do rm $scandir/$i ; done
s6-svscanctl -an $scandir
rm -rf `basedir $live`/`s6-linkname $live`
rm $live
s6-rc-init -l $live -c $newcompiled $scandir
s6-rc -u change $everythingbundle
That's more or less what s6-rc-update will do, of course with
optimizations to avoid restarting everything.
> (`/usr/bin/pm-suspend' works, Fn+F4... not so much, until I run
> /etc/init.d/acpid start once, even if I turn it off afterwards.. why?
> beats me)
Power management on Linux laptops is high-level demonology, and mere
mortals should not dabble in it, lest their souls be consumed. I had a
friend who tried and came back shaking and drooling... it took him a
long while to recover. Fortunately, there's *almost* no permanent
damage to his mind.
--
Laurent
Received on Thu Aug 20 2015 - 08:57:37 UTC