> so while it's nice to have intelligent tools, the tools should be designed to make it easy for people to customize their services to their needs, and not atte

> so while it's nice to have intelligent tools, the tools should be designed to make it easy for people to customize their services to their needs, and not attempt to solve all the problems themselves. in my experience, the simpler the tool is, the less assumptions there are. I'm unimpressed by this argument. I've used sysv-init and upstart (but, to be honest, mostly using the sysv emulation) with Debian and Ubuntu for years, and often see problems the packaged init shell scripts. Bad 'restart' and 'reload' logic, unreliable 'stop', inconsistent output, etc. Upstart's configuration files have been a huge boon- people just screw them up less than shell scripts. Systemd service files are the same. And really, for most things you don't need anything complicated. You want to listen on a socket. If something bad happens, there needs to be an alert and the thing should be restarted. If it can't restart, give it a couple seconds. Eventually a meat person will wander over and figure it out. > this leads you to build in things like monitoring, trending, alerting, quotas, resource limits, and generally design your system better to detect, withstand and prevent fault, instead of just reflexively killing and restarting anything when the eventual problems happen. systemd is great for quotas and resource limits, because they're such a heavy user of cgroups. It's an easy win. For the rest- do you build that in to your server processes? Look, at bottom, all init systems run an executable with arguments. If you need to run a shell script to launch your daemon, you can still run a shell script to launch your daemon. The things that are important are: * Do they do the OS bootstrapping well? * Are they reliable? * What tools do they provide to manage your daemons? SysV and Upstart seem OK at the first two. SysV provides almost no tools, Upstart has a bunch of improvements, though some are arguably busted. Systemd has done a really impressive job at the third. The general response to that is the infinitely disappointing "I have an unspecified unhandled corner case and you are violating the unix philosophy by not using 10,000 poorly written shell scripts". > ... so that when the state of your database/index/locking/etc goes wacky because some job was killed before it could release the lock, you can then write a lock-cleaner-upper and a post-killing-script-execution add-on to systemd. i'm sure they already thought of that (or encountered it on a running system) so it's probably already a feature, but if not: yikes. I posted a link to the man page already, and if you go to it and search for 'ExecStart', you will see a whole list of things- you can specify commands to start, reload, or restart your daemon, to run after stopping, as watchdogs, etc. If you have these problems they can be handled just fine.