On Fri, 26 Sep 2014 12:03:57 +0200 Martin Steigerwald <mar...@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 -- 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/20140926122630.36639...@mydesq2.domain.cxm
