On Thu, Aug 20, 2015 at 1:57 AM, Laurent Bercot <[email protected]> wrote: > 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. :) > Yeah, this is for the special case where you have a daemon that doesn't do readiness notification but also has a non-trivial amount of initialization work before it starts. For most things doing the below talked about oneshot/longrun split is best, but sometimes you need to run that initialization every time (data validators are the most obvious example). > > 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 was using the readiness signal to enforce the timing between udev's heavyweight system prep scripts and everything that depends on udev. Starting udev itself is trivial, and I'm pretty sure that udev doesn't need to guaranteedly be running for other things to start, it just needs to be running for the preparation steps. Hence that "run the sysvinit udev script, immediately afterwards stop udev, start it again supervised" dance. Breaking out into a pair of atomics is a lot more elegant. Why didn't I think of that until last night when I've been experimenting with this since Monday? Dunno. > > 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() ? > It does provide notification, but only if you're running under systemd. At least according to the sd_notify() docs. I'll see about faking up the environment so sd_notify() is happy and report back. > >> 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. > Actually, the more I think about it, the less s6-rc-update will help me avoid reboots in the short term since part of what I need to get back is a pristine post-boot environment. > > 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. > HA! I'm pretty sure the failure is in some acpi policy handling glue code that isn't getting set right. The init.d/acpid script isn't terribly complicated, I simply need to capture the system state before and after the init script is run.
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
