Jeremy Visser <[email protected]> writes: > 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*
The kernel has an option to automatically put stuff into cgroups. Anybody know if that is useful in such a context? IIRC it was targeted only at separate cgroups for each GUI login. >>> > 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. Now I'm wondering if systemd has exceptions for example * VMs started by libvirtd * GUI logins started from nodm such that if you restart the service (because of a software upgrade), it doesn't kill off the VMs. And if it does, who made the decision about which things should be exceptions. I had a problem under Ubuntu 10.04 where libvirtd's upstart service ignored VMs, which meant you could *restart* libvirtd (as happened on security upgrades) without restarting your VMs... but it also meant that at shutdown time, the VMs weren't cleanly shutdown. And it was nontrivial to patch in the latter without also introducing the former. _______________________________________________ luv-main mailing list [email protected] http://lists.luv.asn.au/listinfo/luv-main
