On Thu, 12.08.10 12:01, Paul Menage ([email protected]) wrote: > > On Thu, Aug 12, 2010 at 11:38 AM, Lennart Poettering > <[email protected]> wrote: > > agents for that, and simply forward this to the D-Bus system bus, but my > > stomach revolts every time I get reminded that each time a service exits > > we spawn a little agent process just for that. > > > > Agreed. I don't like release_agent much either. As I said, it was just > for cpusets backwards-compatibility. (Cgroups originally descended > from cpusets in a backward-compatible way. Although in hindsight this > was probably not the best long-term plan, it seemed the only way to > get the system adopted at the time). > > At Google our systemd-like controller relies on spotting the root > process of the service exiting, at which point the service is > considered dead - that way stray lingering processes don't keep the > service unnecessarily alive. But if you want to spot when the service > is dead, you could just poll the contents of the cgroup.procs file to > see if it's empty.
Polling wouldnt really work for us. Firstly, the power management folks would rip my head off if I'd make systemd wake up all the time, and scan all cgroups I am interested in (which might be quite a number) to check whether they are now empty. And I still need my head. Secondly we use this is some case for synchronization: i.e. start one service after another service finished. In such a case it would be suboptimal if we'd have to delay starting of the second service until the next poll interval elapses because we just didn't notice earlier that the first service exited. Lennart -- Lennart Poettering - Red Hat, Inc. ------------------------------------------------------------------------------ This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev _______________________________________________ Libcg-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libcg-devel
