systemd and server use (was: Re: Challenge to you: Voice your concerns regarding systemd upstream)
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.
Ciao,
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
Reply to: