On 15/10/14 10:41, Trent W. Buck wrote: >> > The syntax is not as friendly as upstart, but this is a minor detail. >> > [...] and doesn't interfere with muscle memory by still being able to >> > do "service foo restart". > > upstart supports "service foo restart".
Sorry, shouldn't have put that in the same paragraph. I didn't mean that in anything relating to upstart. I'm saying switching to systemd from upstart/sysvinit doesn't affect my muscle memory. That's all. >> > From a sysadmin perspective killing off pesky child processes is SO >> > last century. You may well argue that every instance where child >> > processes linger when the parent dies is a bug in the application. >> > Well, good luck fixing every one. I'll see you next millennium. In >> > the meantime, I'm enjoying getting actual work done. > > Not sure what you mean by that. There are many services that I run (some free software, some proprietary — either way, out of my domain) that don't close cleanly, leaving behind helper processes. For example, ejabberd leaves behind lots of erlang processes, exim leaves behind other little exims, various Ubiquiti management tools leave java and mongod processes behind...the list is endless. Their supplied initscripts fail at cleaning all this up, and arguably it would be possible to modify every initscript or source code within the application to fix all this, but in the meantime I have work to do. OR, I could put every service in a cgroup and have systemd automagically know what belongs with what with no extra effort. *dusts hands* >> > I find a good analogy for the way cgroups improves management is >> > thinking about the ways in which virtualisation also improves >> > management. > > cgroups were also available long before systemd Sure, I have played with cgroups naked when they first came out, but is hardly what I'd call a friendly UI. systemd makes them usable for dumb folks like me. Most of the "nice" things about cgroups come with systemd for free with no explicit configuration. _______________________________________________ luv-main mailing list [email protected] http://lists.luv.asn.au/listinfo/luv-main
