> From: discuss-bounces+blu=nedharvey....@blu.org [mailto:discuss- > bounces+blu=nedharvey....@blu.org] On Behalf Of Mike Small > > "systemd handles a lot of annoying infrastructure for you; for example, > you do not have to arrange to daemonize programs you run." > > I don't understand this at all. Aren't daemons written as daemons > (giving up controlling terminal and whatever else within their own > code).
Traditional daemons are, because the programmers *had* *no* *other* *choice.* Besides the complexity of actually daemonizing and figuring out how to hook up to a logging facility and manipulate the probably nonstandard running environment, the developer needs to debug their app, so they *also* make it able to run in console mode, and figure out how to manage running in both modes, in both environments. But if you want to create something new, the ability to daemonize any-random-command is a really nice convenience factor; you just write any simple console application or shell script, and it behaves exactly the same on your command terminal as it does when you make it a service under systemd. > "because it actively tracks unit status, conditional restarts are not > dangerous; it shares this behavior with any competently implemented > active init system." > > Don't understand this. What's a conditional restart and why is it > dangerous? What's the difference between an active and passive init > system? A passive system is like /etc/init.d scripts, which brainlessly do as they're told when they're told, and don't make any decisions. If something like mysqld dies, it will not automatically come back up. An active system will notice mysqld died, recognize that it's not supposed to do that right now, and restart it. I know SMF will try to restart a failed service some configurable threshold number of times in a configurable threshold period of time, and if the service continually fails, then the service gets disabled. I assume something similar exists for systemd. _______________________________________________ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss
