[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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 <rrs@researchut.com> 
wrote:
> > 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
> performed:
> 
> 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 
interesting.

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.

  -- Chris

--
Chris Knadle
Chris.Knadle@coredump.us


Reply to: