Benefits servers and system admins the most (Score: 2, Informative) by email@example.com 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: 3, Insightful) by Anonymous Coward on 2014-10-19 20:29 (#2TG1) 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.When a daemon crashes on a production server, we want to know why. We investigate and fix the problem before restarting.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 doesFunny... the only time I ever needed data center staff to intervene was after a botched systemd "upgrade".Automatic service restarts are perfectly safeSimple minded nonsense that will be easily countered by the first 0day exploit that takes advantage of it. Re: Benefits servers and system admins the most (Score: 1) by firstname.lastname@example.org on 2014-10-21 02:20 (#2THH) I should say that when a service crash I prefer to have it restarted as soon as possible on another spare server in order to be able to investigate the crash before reusing the server hosting the crashed service.Therefore, I dunno want systemd.Boot time are irrelevant as a spare server should always be available and a new spare provisionned as soon as the one is used. (hopefully the crashed machine can be bringed back as spare).