5 ms·

Currently using systemd on debian myself, with a few of my own custom .service files and a lot of falling back to sysvinit compatibility -- would love to see mo

by Shish2k 13y ago

Currently using systemd on debian myself, with a few of my own custom .service files and a lot of falling back to sysvinit compatibility -- would love to see more upstream packages contain .service files. Things like "automatically restart if the service dies uncleanly" being handled by the init system are a godsend compared to managing init.d scripts which try to do that job themselves (things like "service start" getting into an infinite restart loop, then "service stop" says "service is not running", because the init script is stuck in a loop but the service itself hasn't been spawned...)

peterwwillis 13y ago
init scripts were originally designed to be "dumb" scripts that only performed one simple task. other scripts could then be written around them reliably, without wondering what the script might be doing in the background other than loading some options and running a program. with modern service management, a lot of extra "intelligence" has been added to how programs are executed and managed. this leads to levels of complexity and uncertainty that eventually lead administrators to hacking the hell out of the system to be able to use it reliably, usually disabling advanced features so they can control such features themselves. on top of that, automation of service restart is a solved problem since... decades ago? it's trivial to have a service restart if it's killed. unfortunately, once such a function is added to your init system, people use it all over the place and don't consider the consequences of services restarting automatically. eventually they get bitten by an unforeseen problem and build in limits to the service restart, etc etc. system automation is a lot harder than most people think.
- bkor 13y ago
  A lot of Uncertainty and Doubt you're raising there... I'm wondering if you actually used systemd?
- krakensden 13y ago
  > it's trivial to have a service restart if it's killed. unfortunately, once such a function is added to your init system, people use it all over the place and don't consider the consequences of services restarting automatically. eventually they get bitten by an unforeseen problem and build in limits to the service restart, etc etc. system automation is a lot harder than most people think. All the more reason to solve it once instead of in a billion different and differently awful addon packages. Plus, systemd is actually better at this than supervisord, daemontools, etc., already because of its cgroup usage- it can reliably kill all children before restarting, even if the process forks. Finally, I encourage you to read the systemd docs: http://www.freedesktop.org/software/systemd/man/systemd.service.html http://www.freedesktop.org/software/systemd/man/systemd.serv... they are quite nice, and show that, in fact, thought has gone into it. > unfortunately, once such a function is added to your init system, people use it all over the place I'm not super on board with this view- for almost everyone, if apache goes down, they want something to restart apache because the problem was probably transient and having apache being down is a Big Problem. Plus, most modern supervisors know about things like "restart throttling".
  - peterwwillis 13y ago
    > All the more reason to solve it see, this is the problem. people don't seem to understand the paradigm of system automation fully. okay, let's take driving a car automatically as an example. where are you going? let's assume we know that all the time. now how do we get there? we have to know where we are to figure out how to get there. and on the way, will we need to stop for gas or a bathroom break? once you figure out those things (and a few more) you can get to the meat of the "code", which is how to maneuver the streets without running into anyone. that part is the easy part, because our variables are based on concrete laws of physics, traffic, etc. the hard part is all those other variables that change based on each trip you take. did we get a flat tire? did someone run into us? is there an unexpected detour? all of these things and more may or may not happen, and you really can't account for them all. 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. 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. > Plus, systemd is actually better at this [..] because [..] it can reliably kill all children before restarting ... 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. (side note: i did investigate systemd initially and found tons of things they either didn't think of, or hadn't released as features yet. i wouldn't have been able to use systemd as a replacement for my current system without some of them!)
    - skorgu 13y ago
      Would you mind naming some of them?
    - justinmk 13y ago
      Oh great, a car analogy.
alextingle 13y ago
/etc/inittab?
bryanlarsen 13y ago
Upstart also has features to handle this scenario. For my purposes, I don't really care whether they choose upstart or systemd, just as long as the init.d scripts go away.
- jethro_tell 13y ago
  It's the cgroups man.
- josteink 13y ago
  I've always liked Linux for the simplicity of services and how they're handled through simple, clear and very understandable init.d scripts. Any distro which takes them away stops being my friend.
  - ianburrell 13y ago
    Systemd lets you still use init.d scripts to run services. It works better with services that use .service files, but it still supports the old ones.
  - rodgerd 13y ago
    Characterising the 16000+ LOC of shell in a Debian 7 init.d directory as simple and clear seems like describing sendmail configuration as easy.
    - vidarh 13y ago
      Sendmail.. Eww.. Whenever one gets the idea of using a macro language to process the configuration files because writing the "raw" configuration format is too difficult, one should sit down and rethink things.
  - bkor 13y ago
    Those init.d scripts are different per distribution. With systemd the same thing is provided in a configuration file. Much simpler, clearer and understandable. Further, "service $FOO status" actually shows you stderr+stdout output, making it easy to debug (in case of failure).
thwarted 13y ago
I've never seen an init.d script that tried to restart something automatically, and attempting to do so within the script itself is folly. Any init.d script that gets into an infinite loop would be deleted immediately. The init.d script should be starting a daemon and then it should exit. If restarting a service like this is required, then the init.d script should spawn something that monitors the daemon (there are numerous tools that do this). Recent syslog-ng comes with one built in. There's so much confusion over /etc/rc, /etc/init.d, /etc/rc?.d, init(8), inittab(5), initscript(5), what they are and how they are related. Getting the machine setup an in a usable state should be divorced from the services that the machine runs, but this is a fine line. Personally, I consider a machine "usable" if the filesystems are mounted, the machine is network accessible, and a configuration management system starts and/or sshd is running so one can login (and even then, this last one is not a strict requirement). Service management beyond that should be handled as just another process running. It's unfortunate that systemd is being pushed as an init(8) replacement, and doesn't seem to support running as a service itself. This being the default, with the option to replace init(8), would most likely lessen the controversy and reduce risk as systemd is developed and rolled out. "Look, you've been doing process management of individual services with systemd already, and you see the benefits; did you know that systemd can also replace init, to get those benefits system-wide?" It's not presented like that, however.

by Shish2k 13y ago

peterwwillis 13y ago

init scripts were originally designed to be "dumb" scripts that only performed one simple task. other scripts could then be written around them reliably, without wondering what the script might be doing in the background other than loading some options and running a program. with modern service management, a lot of extra "intelligence" has been added to how programs are executed and managed. this leads to levels of complexity and uncertainty that eventually lead administrators to hacking the hell out of the system to be able to use it reliably, usually disabling advanced features so they can control such features themselves. on top of that, automation of service restart is a solved problem since... decades ago? it's trivial to have a service restart if it's killed. unfortunately, once such a function is added to your init system, people use it all over the place and don't consider the consequences of services restarting automatically. eventually they get bitten by an unforeseen problem and build in limits to the service restart, etc etc. system automation is a lot harder than most people think.

bkor 13y ago
A lot of Uncertainty and Doubt you're raising there... I'm wondering if you actually used systemd?
krakensden 13y ago
> it's trivial to have a service restart if it's killed. unfortunately, once such a function is added to your init system, people use it all over the place and don't consider the consequences of services restarting automatically. eventually they get bitten by an unforeseen problem and build in limits to the service restart, etc etc. system automation is a lot harder than most people think. All the more reason to solve it once instead of in a billion different and differently awful addon packages. Plus, systemd is actually better at this than supervisord, daemontools, etc., already because of its cgroup usage- it can reliably kill all children before restarting, even if the process forks. Finally, I encourage you to read the systemd docs: http://www.freedesktop.org/software/systemd/man/systemd.service.html http://www.freedesktop.org/software/systemd/man/systemd.serv... they are quite nice, and show that, in fact, thought has gone into it. > unfortunately, once such a function is added to your init system, people use it all over the place I'm not super on board with this view- for almost everyone, if apache goes down, they want something to restart apache because the problem was probably transient and having apache being down is a Big Problem. Plus, most modern supervisors know about things like "restart throttling".
- peterwwillis 13y ago
  > All the more reason to solve it see, this is the problem. people don't seem to understand the paradigm of system automation fully. okay, let's take driving a car automatically as an example. where are you going? let's assume we know that all the time. now how do we get there? we have to know where we are to figure out how to get there. and on the way, will we need to stop for gas or a bathroom break? once you figure out those things (and a few more) you can get to the meat of the "code", which is how to maneuver the streets without running into anyone. that part is the easy part, because our variables are based on concrete laws of physics, traffic, etc. the hard part is all those other variables that change based on each trip you take. did we get a flat tire? did someone run into us? is there an unexpected detour? all of these things and more may or may not happen, and you really can't account for them all. 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. 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. > Plus, systemd is actually better at this [..] because [..] it can reliably kill all children before restarting ... 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. (side note: i did investigate systemd initially and found tons of things they either didn't think of, or hadn't released as features yet. i wouldn't have been able to use systemd as a replacement for my current system without some of them!)
  - skorgu 13y ago
    Would you mind naming some of them?
  - justinmk 13y ago
    Oh great, a car analogy.

alextingle 13y ago

/etc/inittab?

bryanlarsen 13y ago

Upstart also has features to handle this scenario. For my purposes, I don't really care whether they choose upstart or systemd, just as long as the init.d scripts go away.

jethro_tell 13y ago
It's the cgroups man.
josteink 13y ago
I've always liked Linux for the simplicity of services and how they're handled through simple, clear and very understandable init.d scripts. Any distro which takes them away stops being my friend.
- ianburrell 13y ago
  Systemd lets you still use init.d scripts to run services. It works better with services that use .service files, but it still supports the old ones.
- rodgerd 13y ago
  Characterising the 16000+ LOC of shell in a Debian 7 init.d directory as simple and clear seems like describing sendmail configuration as easy.
  - vidarh 13y ago
    Sendmail.. Eww.. Whenever one gets the idea of using a macro language to process the configuration files because writing the "raw" configuration format is too difficult, one should sit down and rethink things.
- bkor 13y ago
  Those init.d scripts are different per distribution. With systemd the same thing is provided in a configuration file. Much simpler, clearer and understandable. Further, "service $FOO status" actually shows you stderr+stdout output, making it easy to debug (in case of failure).

thwarted 13y ago

I've never seen an init.d script that tried to restart something automatically, and attempting to do so within the script itself is folly. Any init.d script that gets into an infinite loop would be deleted immediately. The init.d script should be starting a daemon and then it should exit. If restarting a service like this is required, then the init.d script should spawn something that monitors the daemon (there are numerous tools that do this). Recent syslog-ng comes with one built in. There's so much confusion over /etc/rc, /etc/init.d, /etc/rc?.d, init(8), inittab(5), initscript(5), what they are and how they are related. Getting the machine setup an in a usable state should be divorced from the services that the machine runs, but this is a fine line. Personally, I consider a machine "usable" if the filesystems are mounted, the machine is network accessible, and a configuration management system starts and/or sshd is running so one can login (and even then, this last one is not a strict requirement). Service management beyond that should be handled as just another process running. It's unfortunate that systemd is being pushed as an init(8) replacement, and doesn't seem to support running as a service itself. This being the default, with the option to replace init(8), would most likely lessen the controversy and reduce risk as systemd is developed and rolled out. "Look, you've been doing process management of individual services with systemd already, and you see the benefits; did you know that systemd can also replace init, to get those benefits system-wide?" It's not presented like that, however.