On Thu, Aug 20, 2015 at 1:57 AM, Laurent Bercot <ska-skaware_at_skarnet.org> 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
Received on Thu Aug 20 2015 - 14:43:52 UTC