Re: s6-rc - odd warn logging and a best practices question

From: Laurent Bercot <>
Date: Thu, 20 Aug 2015 10:57:37 +0200

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

> 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.

Received on Thu Aug 20 2015 - 08:57:37 UTC

This archive was generated by hypermail 2.3.0 : Sun May 09 2021 - 19:38:49 UTC