Re: systemd and server use (was: Re: Challenge to you: Voice your concerns regarding systemd upstream)
On Fri, 26 Sep 2014 12:03:57 +0200
Martin Steigerwald <Martin@lichtvoll.de> wrote:
> Hi!
>
> Am Donnerstag, 25. September 2014, 22:53:09 schrieb The Wanderer:
> > On 09/25/2014 at 06:09 AM, martin f krafft wrote:
> > > But dependency creep is unfortunately nothing new ever since we
> > > declared next year the Year of Linux of the Desktop and forgot
> > > that the Universal Operating System should also cater to
> > > non-desktops.
> >
> > In the debian-devel discussions prior to the raising of the TC bug,
> > some of the Debian developers arguing for systemd included among
> > their arguments ones making the case that it would be much better
> > for servers (including the ones which they run) than sysvinit.
> >
> > So it's not that they forgot that, so much as that they have a
> > different perspective and conclusion on whether or not systemd does
> > effectively so cater.
>
> Actually systemd has quite some features which benefits server use.
>
> For example:
>
> 1) It groups services and shell sessions into process control cgroups
> and shields them against each other CPU usage wise. On a systemd
> system you can run stress -c 10000, thus having stress try to hog
> 10000 CPU cores with nonsense calculations, *yet* *still* log in and
> work on a SSH sessions *as if nothing* happened. This is especially
> cool if some service tries to create havoc. Heck, I even demonstrated
> that a systemd based system even can survive an agressive work bomb
> aka perl -e "fork while fork". Yes, I needed to find a killall
> command that does not need to be loaded from disk, a participant of
> one of my trainings knew one fortunately, cause I don´t load anything
> to disk due to no memory to load any executable. But with that
> builtin killall I was able to stop the fork bomb *without* rebooting
> the system.
>
> 2) It is really good at catching the PIDs of the services it runs, no
> matter what funny things they do like double forking. So it exactly
> stops these PIDs and no others. With init script you can basically
> forget about reliably to handle a double forking daemon that doesn´t
> create a PID file.
>
> 3) Compare systemctl service status with /etc/init.d/service status.
> Its obvious that the systemctl output is way more useful to
> administrators.
>
>
> Can these be implemented elsewhere? I´d say yet for 1. Yet 2 and
> partly 3 I think is the core of an init system.
>
> Again, I see advantages. It has some. I need to put my hands before
> my eyes to avoid seeing these. I won´t. Its neither completely black
> nor completely white.
>
> But of course one can only see the advantages if one actually *looks*
> at what systemd provides. You don´t need to love it for that.
Martin,
I don't think anybody's complaining about those features. Those are
excellent features that should be done in PID 1. The only
*technical* thing people are griping about is the gratuitous
entanglement with all sorts of other things, including user programs
and GUI window managers/desktop environments. If systemd was just a
PID1 with the features you enumerate above, I'd be dancing in the
street, not looking for a way out.
SteveT
Steve Litt * http://www.troubleshooters.com/
Troubleshooting Training * Human Performance
Reply to: