Re: Minimal init [was: A few observations about systemd]
On Tue, 2 Aug 2011 15:45:51 -0700 Steve Langasek vor...@debian.org wrote: [...] There's also the matter that if your daemon is being run in the foreground, other services depend on it, and you're not using socket activation, there's ambiguity as to when the service is actually started. A racy startup is a bad thing. Doesn't exactly the same problem exist with classic daemons? I mean, as soon as a daemon being started forked once, the parent instance has no idea whether the forked instance actually managed to complete initialization, and if it did then when. Unless some sort of communication channel is used. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110803130431.19f47c10.kos...@domain007.com
Re: Minimal init [was: A few observations about systemd]
Steve Langasek writes (Re: Minimal init [was: A few observations about systemd]): FWIW, I've gotten feedback from Samba upstream that the upstart job for smbd in Ubuntu, which runs the daemon foregrounded, is concerning to them because foreground mode hasn't been tested upstream in about a decade. No bug reports yet about actual breakage, but if not for the fact that smbd manages to bewilder upstart's daemon tracking code when allowed to daemonize (fix coming soon), I would switch the job to invoke smbd in the usual fashion. If the code is in upstream already then clearly we don't have a problem getting it into upstream. All that's needed is for it to be fixed, and upstream will take those fixes. There's also the matter that if your daemon is being run in the foreground, other services depend on it, and you're not using socket activation, there's ambiguity as to when the service is actually started. A racy startup is a bad thing. I agree. But using a daemon's call to fork() as a proxy for startup notification is IMO absurd. Also I have no objection to socket activation (which is after all what inetd does...). Ian. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20025.22253.531540.625...@chiark.greenend.org.uk
Re: Minimal init [was: A few observations about systemd]
Marc Haber writes (Re: Minimal init [was: A few observations about systemd]): On Tue, 19 Jul 2011 16:55:58 +0100, Ian Jackson ijack...@chiark.greenend.org.uk wrote: No, I don't think so. If these external tools double fork then they are just wrong. Double Forking has been the right way to do it for decades. Demanding from upstreams that they change their software this fundamentally to cater for a new init system is as unrealistic as demanding from upstreams to stay around snooping for new IP addresses that came online after the daemon was started to cater for IPv6. However it is very easy to patch daemons to have an option which causes them not to fork. Most daemons /already/ have a mode in which they don't fork, for debugging purposes. I think we should be quite happy to carry those patches forever, for the few upstreams who won't take them. Ian. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20024.16007.757337.635...@chiark.greenend.org.uk
Re: Minimal init [was: A few observations about systemd]
On Tue, Aug 02, 2011 at 07:14:31PM +0100, Ian Jackson wrote: Marc Haber writes (Re: Minimal init [was: A few observations about systemd]): On Tue, 19 Jul 2011 16:55:58 +0100, Ian Jackson ijack...@chiark.greenend.org.uk wrote: No, I don't think so. If these external tools double fork then they are just wrong. Double Forking has been the right way to do it for decades. Demanding from upstreams that they change their software this fundamentally to cater for a new init system is as unrealistic as demanding from upstreams to stay around snooping for new IP addresses that came online after the daemon was started to cater for IPv6. However it is very easy to patch daemons to have an option which causes them not to fork. Most daemons /already/ have a mode in which they don't fork, for debugging purposes. I think we should be quite happy to carry those patches forever, for the few upstreams who won't take them. FWIW, I've gotten feedback from Samba upstream that the upstart job for smbd in Ubuntu, which runs the daemon foregrounded, is concerning to them because foreground mode hasn't been tested upstream in about a decade. No bug reports yet about actual breakage, but if not for the fact that smbd manages to bewilder upstart's daemon tracking code when allowed to daemonize (fix coming soon), I would switch the job to invoke smbd in the usual fashion. There's also the matter that if your daemon is being run in the foreground, other services depend on it, and you're not using socket activation, there's ambiguity as to when the service is actually started. A racy startup is a bad thing. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Minimal init [was: A few observations about systemd]
On Tue, 19 Jul 2011 16:55:58 +0100, Ian Jackson ijack...@chiark.greenend.org.uk wrote: No, I don't think so. If these external tools double fork then they are just wrong. Double Forking has been the right way to do it for decades. Demanding from upstreams that they change their software this fundamentally to cater for a new init system is as unrealistic as demanding from upstreams to stay around snooping for new IP addresses that came online after the daemon was started to cater for IPv6. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1qkarf-00049e...@swivel.zugschlus.de
Minimal init [was: A few observations about systemd]
Not rocket science about ipc only a loop and two signal to catch: - get SIGING: respawn systemd - get SIGUSR2: spawn a sulogin shell - check if systemd child die, respawn it if needed (rate limited) All the funky stuff is done by a child of init. Hmm If you want to support forking daemons, you'll also want a protocol to signal the child that a monitored process has exited, won't you? -- Juliusz -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87bowqgwmd.fsf...@trurl.pps.jussieu.fr
Re: Minimal init [was: A few observations about systemd]
On Tue, Jul 19, 2011 at 4:42 PM, Juliusz Chroboczek j...@pps.jussieu.fr wrote: Not rocket science about ipc only a loop and two signal to catch: - get SIGING: respawn systemd - get SIGUSR2: spawn a sulogin shell - check if systemd child die, respawn it if needed (rate limited) All the funky stuff is done by a child of init. Hmm If you want to support forking daemons, you'll also want a protocol to signal the child that a monitored process has exited, won't you? No, it is the same problem with systemV init of systemd. Forking daemon are reparented to init and we do not know if exit is genuine or not. It seems this problem (double fork) is the basement of using cgroup under systemd ;) Bastien -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAE2SPAbAd3ZxghLm+UCb-zWXA6ZZdp8btJ=4x4ep66omp1SK=w...@mail.gmail.com
Re: Minimal init [was: A few observations about systemd]
Bastien ROUCARIES writes (Re: Minimal init [was: A few observations about systemd]): Forking daemon are reparented to init and we do not know if exit is genuine or not. Right. It seems this problem (double fork) is the basement of using cgroup under systemd ;) I think messing around with cgroups is a ridiculous way to solve this problem. The right answer is simply to change the daemons to give them an option which causes them not to fork. Then you can just have a single supervision daemon which reaps (and restarts, if desired). I haven't done a survey of the available init replacements but this is not a new concept and I hope that most of them implement it as a possibility. Ian. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20005.41054.544675.800...@chiark.greenend.org.uk
Re: Minimal init [was: A few observations about systemd]
Ian Jackson, le Tue 19 Jul 2011 16:18:54 +0100, a écrit : I think messing around with cgroups is a ridiculous way to solve this problem. The right answer is simply to change the daemons to give them an option which causes them not to fork. Then you can just have a single supervision daemon which reaps (and restarts, if desired). But the daemon may want to start external tools, which may double fork. It's a good thing to be able to catch them too. Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110719153904.gp8...@const.famille.thibault.fr
Re: Minimal init [was: A few observations about systemd]
On Tue, Jul 19, 2011 at 5:18 PM, Ian Jackson ijack...@chiark.greenend.org.uk wrote: Bastien ROUCARIES writes (Re: Minimal init [was: A few observations about systemd]): Forking daemon are reparented to init and we do not know if exit is genuine or not. Right. It seems this problem (double fork) is the basement of using cgroup under systemd ;) I think messing around with cgroups is a ridiculous way to solve this problem. The right answer is simply to change the daemons to give them an option which causes them not to fork. Then you can just have a single supervision daemon which reaps (and restarts, if desired). You could not forbid cgi bin to not fork. I haven't done a survey of the available init replacements but this is not a new concept and I hope that most of them implement it as a possibility. The main problem is they are two concepts of init: 1. immortal child reaper what should not go mad (even malloc should not fail). 2. superdaemon that track/run other daemon and run login The two are orthogonal. The main problem of actual init (even systemd) is that they merge the two concept. Ian. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cae2spaycufxrd9tgs7-d9pl5ognhdaaeqhfes4vcjgyb8vu...@mail.gmail.com
Re: Minimal init [was: A few observations about systemd]
Ian Jackson, le Tue 19 Jul 2011 16:55:58 +0100, a écrit : Samuel Thibault writes (Re: Minimal init [was: A few observations about systemd]): Ian Jackson, le Tue 19 Jul 2011 16:18:54 +0100, a écrit : I think messing around with cgroups is a ridiculous way to solve this problem. The right answer is simply to change the daemons to give them an option which causes them not to fork. Then you can just have a single supervision daemon which reaps (and restarts, if desired). But the daemon may want to start external tools, which may double fork. It's a good thing to be able to catch them too. No, I don't think so. If these external tools double fork then they are just wrong. Well, systemd simply wants to catch that wrong behavior. Even without talking about double fork, a badly implemented server may miss to kill some children. system want's to catch that, and it can be a good thing. Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110719155742.gq8...@const.famille.thibault.fr
Re: Minimal init [was: A few observations about systemd]
Samuel Thibault writes (Re: Minimal init [was: A few observations about systemd]): Ian Jackson, le Tue 19 Jul 2011 16:18:54 +0100, a écrit : I think messing around with cgroups is a ridiculous way to solve this problem. The right answer is simply to change the daemons to give them an option which causes them not to fork. Then you can just have a single supervision daemon which reaps (and restarts, if desired). But the daemon may want to start external tools, which may double fork. It's a good thing to be able to catch them too. No, I don't think so. If these external tools double fork then they are just wrong. They should not double fork; instead, they should either be supervised by the parent daemon or invoked separately by the init system. In either case this can be done with waitpid and does not involve cgroups. Ian. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20005.43278.339527.491...@chiark.greenend.org.uk
