Am Freitag, 26. September 2014, 13:36:27 schrieb Dan Ritter:
> On Fri, Sep 26, 2014 at 01:02:16PM -0400, The Wanderer wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA512
> >
> > On 09/26/2014 at 12:26 PM, Steve Litt wrote:
> > > On Fri, 26 Sep 2014 12:03:57 +0200 Martin Steigerwald
> > >
> > > <mar...@lichtvoll.de> wrote:
> > >> 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.
> > >>
> > >> 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.
> > >>
> > >> 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.
> >
> > Agreed - definitely 2, maybe / maybe-not 3, and definitely not 1.
>
> Start an xterm.
>
> $ bash
> $ ulimit -u 2000
> $ :(){ :|:& };: # THIS IS A FORK BOMB.
>
> watch it run 2000 processes and then start erroring.
>
> open another xterm, verify that they are real.
>
> Close the first xterm.
>
> Verify that the processes are gone.
>
> ulimit can also be applied in PAM at login time for users, or for specific
> daemons.
Good point.
But control groups are more flexible with that: You don´t need to impose a
upper process limit which might be too low.
And still: With stress -c 2000 you slow down a system *a lot* already. So what
limit is sane? Basically I don´t know.
With cpu control groups you do not need that limit.
Ciao,
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1772655.A8I8EHFfra@merkaba
