Re: On init in Debian
On Friday, March 23, 2012 12:05:28, Matt Zagrabelny wrote:
> On Fri, Mar 23, 2012 at 9:39 AM, Ritesh Raj Sarraf <firstname.lastname@example.org>
> > Today, on my typical laptop, boot is not the most important task. It
> > is better to have something well working, fixable (being mere shell
> > scripts and that's what your friend is also pointing). sysvinit serves
> > this purpose well.
> booting is just one of the things systemd/upstart changes.
> I was working with a daemon yesterday (conserver-server, FWIW) and I
> invoke-rc.d conserver-server restart
> This did not *successfully* restart the daemon. The daemon spawned
> some ssh tunnels. These were forked off and had a parent PID of 1, did
> not terminate, and caused a the daemon to not start correctly. It is
> my understanding that systemd (not sure about upstart) would correctly
> handle scenarios like this (by using cgroups.)
It sounds like systemd would handle this via Unix socket handling, starting
the ssh daemon and giving it the Unix socket that systemd had already pre-
allocated for it. And because the Unix socket for ssh was pre-allocated
before starting any of the daemons, the spawned conserver ssh tunnels would
also connect to it and simply "be on hold" waiting for the ssh daemon to
communicate. IMHO this is the feature of systemd that sounds the most
systemd would start conserver-server in its own cgroup, and any child
processes of conserver-server would also be in that cgroup, so the ssh tunnels
would be within that cgroup [and not with the ssh daemon]. This allows for a
way for an administrator to kill all of the processes associated with
conserver-server without having to resort to "killall ssh".
> Switching gears...
> If systemd becomes as widespread as pulseaudio (is becoming), we may
> not have much of a choice about using it or not using it. If a
> critical mass of upstreams use it, we will be somewhat forced to use
> it. In 3-5 years instead of talking about sysvinit replacements and
> the mechanics involved, we will be talking about how to retrofit our
> packages to work around (or without) systemd.
Right now the situation may be somewhat reversed, because in the general case,
daemons need to be patched to work correctly with systemd. [It's been a year
since the video, so perhaps some or many of them have been updated.]
But to answer your concern, someone said it best during one of the talks
during DebConf10: "Debian is software, and software can be changed." i.e
there's no reason to fear, regardless of which direction is chosen.