Hey all,
I've reconfigured one of my debian systems to boot with s6-init/s6-rc
and while trying to debug a timing issue that I think was my own fault
(my "all services" bundle didn't contain my ersatz single-user
bundle). That mucked up a bunch of timing since half of the
initialization stuff wasn't running until I tried to start syslogd.
Anyway, as part of the debugging I found some garbage in verbose
logging that might be logging issues and might be something more
serious.
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
The garbage changes each time, but it's always there.
Also, I know it's aesthetic, but it'd be nice to have a space between
the service name and the text "pre addition" or "post addition."
As for the best practices question. What's the right way to fake
service notification for daemons that don't support it? My udev run
script is the following which while I'm pretty sure it works strikes
me as not the best:
#!/command/execlineb -P
fdmove -c 2 1
if {
foreground { /etc/init.d/udev start }
foreground { /bin/udevadm control --exit }
}
fdmove 1 3
foreground { s6-echo "" }
/lib/systemd/systemd-udevd
Firstly, that seems to be leaving me with a pipe to nowhere on fd 1
that never closes unless I re-fdmove fd2 back onto fd1 (not sure if
that matters mind you, it probably depends on if the service chats
over stdout at all). Secondly, that seems really hacky to me.
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
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?
I'll do some more testing on the potential timing issues that I've
(hopefully) fixed, but so far it's been an interesting experience. I'm
hoping I can sort out the remaining issues without having to force
ordering to the same level as Debian's rcX.d/S0Xservice scripts or
resorting to check loops inside of run scripts. Also, it'll be nice to
have s6-rc-update, I've been rebooting... a lot.
Once I've got my laptop booting correctly all the way into X with the
wireless running and a few things like the sleep button working
(`/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) I'll post some comments, bundle up my init stuff, and see
about making it available for folks who want to go full crazy.
Cheers!
--
"If the doors of perception were cleansed every thing would appear to
man as it is, infinite. For man has closed himself up, till he sees
all things thru' narrow chinks of his cavern."
-- William Blake
Received on Thu Aug 20 2015 - 06:57:56 UTC