Comment 2TGD Re: Benefits servers and system admins the most

Story

Is it time to fork Debian?

Preview

Benefits servers and system admins the most (Score: 2, Informative)

by evilviper@pipedot.org on 2014-10-19 18:37 (#2TFW)

I object to the frequently repeated assertion that system admins don't want systemd, and that it only benefits desktop users.

SysVinit scripts don't have any way to restart services that have quit/crashed. That is EXTREMELY important on servers, and it's absence is a notable missing feature on Linux. There are various add-ons that do this, like daemontools, but they can't replace SysVinit, so you're stuck maintaining two mutually incompatible methods for running services.

I don't care about boot-up times, but not being able to have all system services automatically restarted (without human intervention at 3am), should anything happen to them, is a glaring failure on Linux, putting it a couple decades behind its competitors.

Debugging a system, and/or rebooting it every time it comes up but a network file system didn't mount in-time... Getting paged at 3AM every day, because after 2 years of uptime, crond happened to crash and across hundreds of servers that's a daily occurrence... etc. These are all very important to any server admins, and hardly matter to desktop users.

And to preempt the common responses:

You would NOT want to be paged at 3am just because crond crashed after 2 years of uptime. It's crazy to claim someone needs to investigate every such happenstance. It's also crazy to claim you should rewrite all your startup scripts so every system service is run out of daemontools. After all.. ANY service that you need running is "critical" and failure can't be ignored. Right now, these system restarts are typically performed by poorly-paid NOC personnel, who understand less about the services in question than systemd does. And needing to have NOC folks working around the clock is prohibitive for small shops (who have system admins who would like to sleep through the night) and increases the TCO for large shops, who made need a large number of NOC employees because restarting services becomes a full-time job to the exclusion of other job duties, given enough servers.

Automatic service restarts are perfectly safe. If there was any such issue, it would be looming over daemontools since forever, and the widespread adoption of systemd by every distro out there just serves to show the experts just might know something. Those claiming systemd is bad and useless have to come up with vast conspiracy theories to explain away the enthusiastic and widespread adoption.

I hate to jump into the systemd flame war yet again, where typically the least-informed and least affected shout the loudest. After all, there's no benefit to interrupting the detractors, because every distro out there is already on the side of systemd, and the ranting and moaning on sites like this won't change that.

Re: Benefits servers and system admins the most (Score: 2, Insightful)

by bryan@pipedot.org on 2014-10-20 02:18 (#2TGD)

Some daemons are built to recover from crashes and restart their own worker processes. For example, Apache's main pid is mainly in charge of spawning new child processes to do the actual work. The children can even be configured to terminate themselves after serving X number of requests.

However, some daemons, such as mysql end up relying on a shell script to do this task. I've always thought of the mysqld_safe script as being an ugly hack. Wouldn't a real program be a better fit for this? And if you make a generic enough service monitor, couldn't you use it for more than just one program?

The traditional inetd process is another example. The post-fork method of operation is just too slow for modern tasks such as web page serving. But systemd does have some interesting ideas on how to fix it.

History

2014-10-20 02:18
Some daemons are built to recover from crashes and restart their own worker processes. For example, Apache's main pid is mainly in charge of spawning new child processes to do the actual work. The children can even be configured to terminate themselves after serving X number of requests.

However, some daemons, such as mysql end up relying on a shell script to do this task. I've always thought of the mysql_safe script as being an ugly hack. Wouldn't a real program be a better fit for this? And if you make a generic enough service monitor, couldn't you use it for more than just one program?

The traditional inetd process is another example. The post-fork method of operation is just too slow for modern tasks such as web page serving. But systemd does have some interesting ideas on how to fix it.
2014-10-20 02:19
Some daemons are built to recover from crashes and restart their own worker processes. For example, Apache's main pid is mainly in charge of spawning new child processes to do the actual work. The children can even be configured to terminate themselves after serving X number of requests.

However, some daemons, such as mysql end up relying on a shell script to do this task. I've always thought of the mysqld_safe script as being an ugly hack. Wouldn't a real program be a better fit for this? And if you make a generic enough service monitor, couldn't you use it for more than just one program?

The traditional inetd process is another example. The post-fork method of operation is just too slow for modern tasks such as web page serving. But systemd does have some interesting ideas on how to fix it.

Moderation

Time Reason Points Voter
2014-10-20 03:32 Insightful +1 evilviper@pipedot.org

Junk Status

Not marked as junk