On Fri, 12 Jun 2015 17:31:10 +0100 Matthew Melton <m...@mjmworks.co.uk> wrote:
> > > ---- Steve Litt wrote ---- > > > Hi all, > > > > When Irrwahn mentioned that cups needed depoetterization, my first > > thought was "what in the world does cups need with systemd? And > > then I realized the problem. > > > > Like a lot of us, I'm on the supervis...@list.skarnet.org mailing > > list, where they discuss all things init, mainly from the > > perspective of daemontools-inspired inits. For months, literally, > > the supervision list has been wringing its hands over the very real > > problem that, for process dependency purposes, one must know that > > process X is not only running, but ready to handle its business. > > Knowing process X is running isn't sufficent, because some > > processes take a long time between running and being ready for > > business. Cough, cough, dhclient, cough cough. I mean, look at the > > kludge I use to make sure the network's running before running > > sshd, for instance: > > > > ====================================== > > #!/bin/sh > > if ! ifconfig | grep "\s*inet addr:"; then > > sleep 5 > > exit 1 > > fi > > exec /usr/sbin/sshd -d -q > > ====================================== > > > > Systemd "offers" daemons the sd_notify(3) call, by which they can > > inform systemd that they're ready. I said "offers", because as soon > > as a critical mass of daemons have drunk the Kool Aid, it will be > > about as much of an "offer" as "Windows certified" is an "offer". > > In fact, I fully expect that, before long, daemons will need to > > become "systemd certified" to be included in some distros. > > > > The tough thing is, this ready-notification is actually a good idea > > that solves a lot of problems and presents a lot of opportunities. > > It's just too bad it was "standardized" by an atrocity like > > systemd. Over and over again, you can expect every single daemon to > > become poetterized as it adopts sd_notify(3). > > > > In the beginning, depoetterization of these daemons might consist > > solely of removing package dependencies, but sooner or later > > non-optional sd_notify will become manditory for systemd > > certification. Why? You know why. > > > > So we play their silly game and code a stub sd_notify, that does > > nothing. Or perhaps even better, lists the daemon as ready for > > business in some kind of table that init can refer to. > > > > I don't know much about sysvinit, but with daemontools-encore, and > > probably runit, it wouldn't be super-hard to have a table of all > > services with all of their dependencies, and when all a service's > > dependencies become ready for business, the service is run > > affirmatively. This is probably what systemd had in mind in the > > first place: Too bad they had to tack on all the other crap. > > > > So, if we code up a dummy sd_notify to interface replace the one > > from systemd, we can make ongoing future depoetterization easier, > > and very possibly give ourselves a better, easier to administer > > init. > > > > SteveT > > > > Steve Litt > > June 2015 featured book: The Key to Everyday Excellence > > http://www.troubleshooters.com/key > > _______________________________________________ > > Dng mailing list > > Dng@lists.dyne.org > > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng > > > Could a convention be to use the logs to notify any listeners that > the service has been successfully started? Since most services use > the logs anyway would it be trivial to have a /var/log/running log? > > A scripted dependency can check the log using grep or whatever. > Before starting. No need for another binary. > > A bit like how fail2ban does its magic... > > I'll go back to lurking. > > Matt Hi Matt, I don't know. How's that for an authoritative answer? The one thing I *do* know is that we need to provide a sd_notify interface, even if it does nothing at all and drops passed information on the floor. Later, if we decide to actually *use* the info sent us via sd_notify, I don't know whether the proper venue for that use would be logs or something else. Personally, I'd really prefer we *don't* use dbus for these notifications. I know that's theoretically what dbus is for, but I don't trust dbus as far as I can throw the rocky mountains. I'm at a disadvantage here because the only process management I really understand is daemontools and daemontools-encore. SteveT Steve Litt June 2015 featured book: The Key to Everyday Excellence http://www.troubleshooters.com/key _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
