Debian Developer Resigns From The Systemd Maintainership Team

[Guest]

SystemD, is good for desktop's(not my machines , thanks)...

Sisvinit is not perfect , but it is good for servers...you can adapt things and control them without go in code, or binary...

So you found a patern like I have found!
If Debian(redhat, etc) want to use SystemD in desktop's fine
But I want sysvinit in my small 400 server high availability center...I will not use systemD here!!

So Debian need to chose:

1) Debian will be a desktop distro, and so, it will left server stuff..
2)Debian will stay in server and left the ideia of Desktop's for ubuntu
3)Debian will release a option to the people to choose what it will use...and in this case can be in Server and in Desktop!

The experienced sysadmins out there does not go with SystemD, which will get Debian out of their server clusters...

Debian need to choose what they want...after that programmer/Users and SysAdmins can choose if they will continue to use Debian or have to switch do Slackware or another..

This is not the end of the world...but Debian HAVE to make a decision on this!

regards

"systemd is for desktops, sysvinit is for servers" - who invented this myth?

[FLHerne]

Sisvinit is not perfect , but it is good for servers...you can adapt things and control them without go in code, or binary...

But I want sysvinit in my small 400 server high availability center...I will not use systemD here!!

You run a 400-server cluster, in which you 'adapt things and control them' through the init system often enough that you care, but you can't spell the name (SysVinit) of the init system you supposedly use and adapt?

(Not a nitpicking thing, 'sysv*' is part of various commonly-used commands and config files. Used several times, so not a typo).

Trolls are bad enough without pretending they have a clue.

[gens]

"systemd is for desktops, sysvinit is for servers" - who invented this myth?

HA load balancers are usually just the kernel, a couple programs like ssh and ngix and the libraries to run them
systemd has nothing to do on that server, not even udev

[You-]

"systemd is for desktops, sysvinit is for servers" - who invented this myth?

It doest matter wh the haters do, Debian has chosen systemd as the default init. It will remain so for the life of Debian 8. Even if they chase the developers away, this wont change.

Maybe there will be different option for Debian 9. Though I would guess it wont be sysv init, because when evaluating options on the tech committee if there was a unanimous decision, it was to not use sysv init.

(the Debian vote on uncoupling AFAIK finishes tomorrow too, that should be interesting.)

[gens]

You run a 400-server cluster, in which you 'adapt things and control them' through the init system often enough that you care, but you can't spell the name (SysVinit) of the init system you supposedly use and adapt?

(Not a nitpicking thing, 'sysv*' is part of various commonly-used commands and config files. Used several times, so not a typo).

Trolls are bad enough without pretending they have a clue.

[monraaf]

Actually systemd is really nice for servers.

With sysvinit, if your daemon dies, it does not care.
Because it was started by a friggin shell script, which actially quit the very first second.

Systemd restarts failed services and those that depend on it. Very nice for servers.

With sysvinit you need ugly hacks like monit to check if the pid (if the pidfile was created right) is still alive... just one of the things sysvinit does really bad, and i don't underatand why people shed a tear. I'd probably underatand if people fought for upstart or anything modern. But why badly written shell scripts that fail more often than they work?

[gens]

Actually systemd is really nice for servers.

With sysvinit, if your daemon dies, it does not care.
Because it was started by a friggin shell script, which actially quit the very first second.

Systemd restarts failed services and those that depend on it. Very nice for servers.

With sysvinit you need ugly hacks like monit to check if the pid (if the pidfile was created right) is still alive... just one of the things sysvinit does really bad, and i don't underatand why people shed a tear. I'd probably underatand if people fought for upstart or anything modern. But why badly written shell scripts that fail more often than they work?

init, the sysvinit binary, can do that (for example the "respawn" flag is set for agetty)

and no, you don't want to do that on a server and you don't use monit/systemd to check if your server is online

[Gusar]

"systemd is for desktops, sysvinit is for servers" - who invented this myth?

Good question. It's repeated again and again. Even though it doesn't make sense. Desktops mostly benefit from the companion daemons (timedated, localed, logind). It's exactly on the server that systemd's logging abilities, its service supervision, its resource management abilities, etc, really shine.

For example, do a "service blah status" on CentOS 6. It'll say something like "Service blah running on PID 1234". Wow how very useful! Now do "systemctl status blah" on a machine running systemd. And you'll get detailed info on the service, including a few lines from the journal. That's just one tiny example, but it already makes a big impact.

[monraaf]

Sysvinit can restart a getty - because it doesn't detach.

It doesn't support this with shell based "sysv init scripts".

Also monitoring != running /etc/init.d/blah status manually to check if the service is up...

[gens]

For example, do a "service blah status" on CentOS 6. It'll say something like "Service blah running on PID 1234". Wow how very useful! Now do "systemctl status blah" on a machine running systemd. And you'll get detailed info on the service, including a few lines from the journal. That's just one tiny example, but it already makes a big impact.

from what i linked above:
"slm's answer has more about this sort of init querying but the problem with trusting that is it only really tells you if a process is still running. Your httpd's main process could be running but in some way deadlocked."

that's the proper way to see if your server is running
to check every couple minutes if it is serving, that is