/sys/fs/cgroup/systemd/ is systemd's turf and cgclear and related tools should not interfere with it.
See bug #626794 for the discussion that prompted this.
Basically, cgclear messes around with anything the user has a right to mess around with :-). So is systemd protected from users? In any case, this does need to be fixed up, and we need a mechanism to work with other users. I will try to post a fix asap which will paper over the systemd issue, and will look for a longer term fix after that.
Having looked at both projects, I am pretty sure that they are in conflict, as they overlap in scope. I think the long term solution for Fedora is to pick one.
(In reply to comment #3) > Having looked at both projects, I am pretty sure that they are in conflict, as > they overlap in scope. I think the long term solution for Fedora is to pick > one. Seriously? I am pretty sure I asked you not to FUD in the other bug. How do they overlap in terms of scope. systemd is an init system. It is not the windows registry equivalent of Linux. Yes, systemd uses cgroups. So do others. The long term solution for Linux (note, I am not picking any distro here) is to consolidate that use in libcgroup, and unify it. Not picking one over the other. Also, note, Lennart has been kind enough to provide us a list of requirements. I have been in the middle of some serious travel, but those items on his list are being given attention.
(In reply to comment #4) > Seriously? I am pretty sure I asked you not to FUD in the other bug. How do > they overlap in terms of scope. I'm not sure you understand what the term "FUD" means. Please look it up. > systemd is an init system. It is not the windows registry equivalent of Linux. > Yes, systemd uses cgroups. So do others. systemd uses cgroups in a wide-reaching way. It categorizes every process on the system. cgrules.conf and whatever reads that also categorizes processes on the system. Is that not overlap? Maybe I am misunderstanding something crucial, which is why I asked for clarification on a number of things. Rather than calling my questions "FUD", you could have answered them. > The long term solution for Linux > (note, I am not picking any distro here) is to consolidate that use in > libcgroup, and unify it. Not picking one over the other. I'm still confused on the *boundaries* between libcgroup and the included tools. Can you clarify this a bit further?
(In reply to comment #5) > (In reply to comment #4) > > Seriously? I am pretty sure I asked you not to FUD in the other bug. How do > > they overlap in terms of scope. > > I'm not sure you understand what the term "FUD" means. Please look it up. > umm. Stop implying libcgroup should die. > > systemd is an init system. It is not the windows registry equivalent of Linux. > > Yes, systemd uses cgroups. So do others. > > systemd uses cgroups in a wide-reaching way. It categorizes every process on > the system. Only for the hierarchy it controls. As I have conceded elsewhere, libcgroup should *not* be interfering with that, which this bug is about. > cgrules.conf and whatever reads that also categorizes processes on > the system. Is that not overlap? Maybe I am misunderstanding something crucial, > which is why I asked for clarification on a number of things. Yes. cgrules allows you to specify *which* hierarchies you want to control. You can very easily not have it manipulate the systemd hierarchy which is all what system (should) care(s) about. > Rather than > calling my questions "FUD", you could have answered them. > No. You stated that either-or should exist. You made the claim you have taken a look at the project. Please do what you claim, as opposed to claiming them and making statements. Also, engage the developers to handle your issues instead of claiming their project should die. > > > The long term solution for Linux > > (note, I am not picking any distro here) is to consolidate that use in > > libcgroup, and unify it. Not picking one over the other. > > I'm still confused on the *boundaries* between libcgroup and the included > tools. Can you clarify this a bit further? libcgroup is a library which manipulates cgroups. There is a nice document (albeit a bit dated) at http://libcg.sf.net which describes the project's aims. Since then it has progressed quite a bit, in no small measure thanks to the input given to us by the systemd developers. I do not really care about the tooling around it. If a better tool comes about, I am all for it. What I really care about it unifying the users of cgroups to use the same library, which we are working on. libcgroup is also a convenient place to store the common tools, which is what has happened. If you feel there is a deficiency somewhere, engage us upstream with patches and useful discussions and opposed to all this riling up. You will find us quite willing to accept patches.
(In reply to comment #6) > umm. Stop implying libcgroup should die. I think you are being very sensitive. There should be one place to set policy. If that place is the libcgroup configuration, awesome. But systemd is also in this same space (and you are underestimating it if you think it's not), and I do not want there to be confusing overlap. Maybe the systemd developers are not at all interested in exploring that space further and *should* make use of libcgroup. That is why I asked that question! > I do not really care about the tooling around it. If a better tool comes about, > I am all for it. What I really care about it unifying the users of cgroups to > use the same library, which we are working on. libcgroup is also a convenient > place to store the common tools, which is what has happened. If you feel there > is a deficiency somewhere, engage us upstream with patches and useful > discussions and opposed to all this riling up. You will find us quite willing > to accept patches. Thank you. I think we are actually in agreement here. It is my impression that: 1) systemd should use libcgroup 2) the current toolset from libcgroup should be split into "cgroup-tools" or somesuch, to avoid confusing conflation with the library. 3) systemd might (and I think, probably should), in the future, take over some of the task management and classification tools currently provided (but not used by default in Fedora) by cgred, etc. Does that sound reasonable?
(In reply to comment #7) > (In reply to comment #6) > > umm. Stop implying libcgroup should die. > > I think you are being very sensitive. > Probably. > There should be one place to set policy. If that place is the libcgroup > configuration, awesome. But systemd is also in this same space (and you are > underestimating it if you think it's not), and I do not want there to be > confusing overlap. systemd is involved in a very small part of this space. Should there be just one place for all the configuration, in most cases that is the right answer. But here systemd needs to have its hierarchy up early, and so it needs to setup the hierarchy early enough and that is the right answer. OTOH, what cgconfig does is set up the rest of the hierarchies later on, as the user wants it. Now regarding cgrules.conf, it can very easily be set to not mess around with systemd, I believe it is documented in the manpages, if not, we will update it soon enough. > Maybe the systemd developers are not at all interested in > exploring that space further and *should* make use of libcgroup. That is why I > asked that question! > As I have mentioned earlier, systemd upstream ahs been involved in libcgroup upstream development. Infact, I have stated that for the time being, my libcgroup development goals are driven by systemd's requirements. It is just that I am in the middle of serious travel and paper submission, which is why it is not getting my full bandwidth. Lennart has told me that he will not use libcgroup till we support his requirements, whcih is perfectly fine, and once we have taken care of his requirements, he should move back. > > > > I do not really care about the tooling around it. If a better tool comes about, > > I am all for it. What I really care about it unifying the users of cgroups to > > use the same library, which we are working on. libcgroup is also a convenient > > place to store the common tools, which is what has happened. If you feel there > > is a deficiency somewhere, engage us upstream with patches and useful > > discussions and opposed to all this riling up. You will find us quite willing > > to accept patches. > > Thank you. I think we are actually in agreement here. > > It is my impression that: > > 1) systemd should use libcgroup I think I have handled this earlier. > 2) the current toolset from libcgroup should be split into "cgroup-tools" or > somesuch, to avoid confusing conflation with the library. I think that is reasonable. Jan should be the right person if he agrees with this change. > 3) systemd might (and I think, probably should), in the future, take over some > of the task management and classification tools currently provided (but not > used by default in Fedora) by cgred, etc. > Maybe, maybe not. I am not in agreement with systemd being the right tool for it. It does a great job with init systems. I mean, I have been running it since the first time it started booting. But, I am not sure if it should be handling classification, which would require it to have some way of getting user input in, which is additional complexity, and something that is orthogonal to its design. Lennart is a better judge for that. However, if they do a better job, then of course, we should go for that solutuion, and if it is a stand alone tool, we can easily merge it with libcgroup.
Hmm, any update on this issue? Jan, you wanted to prepare a patch IIRC?
I am not sure what the current status is, I have patch (cgclear unmounts only stuff that cgconfig mounted), Dhaval does not like it and prepares his own solution. But what the solution is, I don't know, he's travelling.
fix coming up in a few minutes. Sorry, lost the latest procses of getting fedora packages out.
Created attachment 442828 [details] Untested Patch I am not sure how well this will work, since I am not in a position to test this. But this is my band-aid for now. This shuold ignore all systemd stuff. OTOH, if systemd is using libcgroup, then I will need to move this fix into cgclear.c. This will work just fine, since systemd enforces that it is mounted separately from other subsystems. If it does not work, I think it should be trivial to fix up. The right fix as Lennart and I discussed should be in the upstream sourcse in about a month or so.
also, the patch is simple, so is not as risky as Jan's original patch.
I applied Dhaval's patch. We'll sort it up properly upstream.