When a double-forking daemon spawns the shortlived forking process and
we fail to classify it in time, the child does not inherit (the
intended) cgroup membership.

We could process all children after receiving PROC_EVENT_FORK to remedy
this. But since we already have the timestamp logic introduced in
    8953fc07c0498d1ddd9a04dc549ffb85862f4c5f
and it may be too much work for all fork(2) calls, we extend the usage
of parent_info by assuming the parent would have changed its cgroup
membership by our actions even if it terminated quickly.

Signed-off-by: Michal Koutný <mkou...@suse.com>
---
 src/daemon/cgrulesengd.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/src/daemon/cgrulesengd.c b/src/daemon/cgrulesengd.c
index 0d288f3..75e3548 100644
--- a/src/daemon/cgrulesengd.c
+++ b/src/daemon/cgrulesengd.c
@@ -478,8 +478,9 @@ int cgre_process_event(const struct proc_event *ev, const 
int type)
        ret = cgroup_change_cgroup_flags(euid, egid, procname, pid,
                                                 CGFLAG_USECACHE);
        if ((ret == ECGOTHER) && (errno == ESRCH)) {
-               /* A process finished already and that is not a problem. */
-               ret = 0;
+               /* A process finished already but we may have missed changing 
it,
+                * make sure to apply to forked children. */
+               ret = cgre_store_parent_info(pid);
        } else if (ret) {
                flog(LOG_WARNING,
                        "Cgroup change for PID: %d, UID: %d, GID: %d, PROCNAME: 
%s FAILED! (Error Code: %d)\n",
-- 
2.16.4



_______________________________________________
Libcg-devel mailing list
Libcg-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libcg-devel

Reply via email to