Re: [systemd-devel] systemd and cgroups
El 13/01/14 19:42, Dominique Michel escribió: Or I am wrong and systemd will not work without the kernel cgroups? systemd *requires* cgroups, what you can disable are certain controllers. I do not know to which extent this ability to disable controllers will remain in place. Whatever is decided is AFAIK being worked on with the collaboration of cgroup developers. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd and cgroups
Le Mon, 13 Jan 2014 19:39:57 +, Colin Guthrie a écrit : > Hello, > > You're approaching this whole thread from a fixed position and > therefore seem to be seeing *everything* as negative and > problematic. Hi, You are partly right on this. In the mean time, I read other things on the cgroups and systemd, and I know realize that things are not as bad I was thinking. I also realize you are working hard to find solutions to many problems. > > Rather than coming here with problem and looking for a solution, > you've arrived with a solution already designed and seem to be > complaining that it won't work. > > There WILL be a solution to your *problem* but it might not be > achieved via the design you have in mind. > > It could be due to the semantics of how you express the requirement > means you have to think about the problem differently. I now understand that. But it was not obvious at all at the time I was fighting with a randomly freezing system. And nobody at that time was able to point me on the right direction. So I must thank the peoples on that list for that. > > Much of what you say below is simply incompatible with the upstream > kernel single-cgroup manager model that is being pushed. You cannot > have a "custom cgroup configuration" directly under this model: the > configuration has to be expressed indirectly as user and administrator > friendly declarative statements in various unit files which ultimately > map to cgroup configurations (mostly as an implementation detail). As a user and administrator, I don't care as long I can make it to suit my needs. > > > > Too late, I shifted the distribution because I was in urgent need > > of a good working system on that box. > > Well, this has obviously given everyone the time to properly respond > and help you with your problem. If I didn't know better this whole > conversation would appear to be just a random complaint FUD email > rather than one seeking to gain knowledge. Before I shifted the distribution, I really try hard to make it to work with systemd, that under a few weeks. That imply this is not a random complain. But you are right on one thing, as I understand that issue now, I was not following the right path and I should have contacted that list at that time. > > >>> Again, the point of the cgroups is to be able to adapt the system > >>> to any kind of workload, and to have systemd that take control of > >>> that good and flexible system, and at the same time, doesn't > >>> provide a way for an user to adapt the default configuration to > >>> its own need, is just a big design bug, which start with Lennart > >>> failure to take in account the fact that all users are corner > >>> cases by definition, because all users are doing different kind > >>> of works with their computers. > >> > >> That's not the goak of cgroups at all, sorry. > > > > Lennart is very clear in his email, "normal" users run a GUI. > > That is completely untrue. You have read far too much into that > statement and the examples provided there. Let Lennart answer for > himself before you make rash generalisations. Maybe I over reacted, but it is what inspire me the lecture of that message. > > > So sure, according to that mail, the goal of the crgoup interface of > > systemd is just to run a GUI > > Completely untrue and certainly not how I read the email. > > > And yes, as I want (my choice) a GUI that is not in my way, I am > > allergic to a GUI that interfere with a good working system (like > > gnome and its *kit madness), but that's another issue. > > Yes, it's another issue and one *completely* irrelevant to this > mailing list. Such negativity in comments is *highly unwelcome* here. > Please keep it to yourself or for slashdot posts. Come on, I don't post to slahdot, I just have better things to do. If I am here, this is because I think it is a problem with the actual state of systemd, and I also think users must be aware of it if they want to avoid issues like freezing computers during a migration to systemd. I was maybe over reacting on a few things, inclusive on Lennart statement and systemd usability, and I apologize for that, but the complete and repetitive system freeze I get was 100% real. > > > The fact is that nobody on the Debian forum was able to help me, or > > even aware of the existence of that documentation. Or they all was > > in holiday at that time. > > Quite possibly. Complaining that nobody held your hand here is > somewhat off topic however. It doesn't change the fact that the > documentation for systemd is extremely extensive and one of the best > documented open source projects I've ever worked with. It may be. But it is something new, something that, as my little experience with it showed me, nobody outside of a little community seam to know and understand. > > > Anyway, I did read it but was completely unable to make it to work, > > whatever I try. It is only when I read Lennart email yesterday, I > >
Re: [systemd-devel] systemd and cgroups
Hello, You're approaching this whole thread from a fixed position and therefore seem to be seeing *everything* as negative and problematic. Rather than coming here with problem and looking for a solution, you've arrived with a solution already designed and seem to be complaining that it won't work. There WILL be a solution to your *problem* but it might not be achieved via the design you have in mind. It could be due to the semantics of how you express the requirement means you have to think about the problem differently. Much of what you say below is simply incompatible with the upstream kernel single-cgroup manager model that is being pushed. You cannot have a "custom cgroup configuration" directly under this model: the configuration has to be expressed indirectly as user and administrator friendly declarative statements in various unit files which ultimately map to cgroup configurations (mostly as an implementation detail). > Too late, I shifted the distribution because I was in urgent need of a > good working system on that box. Well, this has obviously given everyone the time to properly respond and help you with your problem. If I didn't know better this whole conversation would appear to be just a random complaint FUD email rather than one seeking to gain knowledge. >>> Again, the point of the cgroups is to be able to adapt the system to >>> any kind of workload, and to have systemd that take control of that >>> good and flexible system, and at the same time, doesn't provide >>> a way for an user to adapt the default configuration to its own >>> need, is just a big design bug, which start with Lennart failure to >>> take in account the fact that all users are corner cases by >>> definition, because all users are doing different kind of works with >>> their computers. >> >> That's not the goak of cgroups at all, sorry. > > Lennart is very clear in his email, "normal" users run a GUI. That is completely untrue. You have read far too much into that statement and the examples provided there. Let Lennart answer for himself before you make rash generalisations. > So sure, according to that mail, the goal of the crgoup interface of > systemd is just to run a GUI Completely untrue and certainly not how I read the email. > And yes, as I want (my choice) a GUI that is not in my way, I am > allergic to a GUI that interfere with a good working system (like gnome > and its *kit madness), but that's another issue. Yes, it's another issue and one *completely* irrelevant to this mailing list. Such negativity in comments is *highly unwelcome* here. Please keep it to yourself or for slashdot posts. > The fact is that nobody on the Debian forum was able to help me, or > even aware of the existence of that documentation. Or they all was in > holiday at that time. Quite possibly. Complaining that nobody held your hand here is somewhat off topic however. It doesn't change the fact that the documentation for systemd is extremely extensive and one of the best documented open source projects I've ever worked with. > Anyway, I did read it but was completely unable to make it to work, > whatever I try. It is only when I read Lennart email yesterday, I > understand why it was not working: systemd is designed to not work with > custom cgroup configurations. No, systemd is designed to *manage* your custom cgroup configurations. It abstracts cgroups away to pretty much an implementation detail. You can still get the needed *solution* to your problem. > And if it is already stated in the doc that systemd will not work with > custom cgroup configurations, you must emphasis more on that issue, so > that worried users doesn't miss it, and doesn't waste their time with > this. Keep in mind that the single-writer principle is still relatively new. Everything has to be adapted to it and systemd has moved very quickly to match the upstream kernel needs. As time goes on, documentation in this area will improve. >>> So, don't say me I could have done this or that, that's not my >>> point. My major point is GNU/Linux have always been about choices, >> >> That's not true at all, it's never been about choices. > > Well, you don't need to say anything more, we just don't have the > same conception of Free Software. For me, Free Software is about 5 > fundamental liberties, and liberty is all about choices. Your "choice" exists in your ability to view, understand and write the code yourself. Whether someone's crazy whim or configuration (not necessarily referring to your current requirement) has to be supported by every utility in the open source stack is completely different. People hear the word "choice" and build up a whole expectation around it's dictionary definition to the extent that they presume everyone must bend over backwards to support any crazy idea they come up with. I'm sorry, but this has never and will never be true. http://islinuxaboutchoice.com/ >> If you wish to use your own cgroup configurations, y
Re: [systemd-devel] systemd and cgroups
Le Sun, 12 Jan 2014 16:07:45 -0800, Greg KH a écrit : > On Sun, Jan 12, 2014 at 11:48:56PM +0100, Dominique Michel wrote: > > I need that pc for production, so I rapidly installed another > > distribution without systemd. So this problem is solved for me, but > > that doesn't solve that to force any user to use a default > > configuration without any possibility of user setup, and without > > documentation that can allow an user to do that, is just a design > > fault. > > That sounds like a distro issue, please take this up with your distro > developers, this isn't a systemd issue. Too late, I shifted the distribution because I was in urgent need of a good working system on that box. > > > Again, the point of the cgroups is to be able to adapt the system to > > any kind of workload, and to have systemd that take control of that > > good and flexible system, and at the same time, doesn't provide > > a way for an user to adapt the default configuration to its own > > need, is just a big design bug, which start with Lennart failure to > > take in account the fact that all users are corner cases by > > definition, because all users are doing different kind of works with > > their computers. > > That's not the goak of cgroups at all, sorry. Lennart is very clear in his email, "normal" users run a GUI. Sorry, but I am not abnormal and I do some work with my computer. The GUI is just an accessory for me, and as long it is not in my way and provide me a decent mouse focus policy and plenty of keyboard short cuts, 2 things essential for my work flow, I am happy with it. So sure, according to that mail, the goal of the crgoup interface of systemd is just to run a GUI, and this is precisely why it doesn't work for me: it doesn't allow custom cgroup configuration for people that want to do something more than running a GUI. And yes, as I want (my choice) a GUI that is not in my way, I am allergic to a GUI that interfere with a good working system (like gnome and its *kit madness), but that's another issue. > > > Today, during a forum discussion on the cgroups, someone gave > > the link above with the different Lennart's statements. I begun to > > understand. Later also today, I finally find some documentation on > > the freedesktop web site. But that's too late, I need this pc for > > production, and I have other things to do than risking a hard disk > > failure because of a freezing system, so I will not reinstall > > Debian. And for that, I didn't even read more of that doc than a few > > lines. I just lost the interest of the good idea that systemd is, > > that because of its catastrophic implementation that can cause so > > severe regression like system freeze, and its almost complete lack > > of documentation. > > I don't think you have looked, systemd is the best documented piece of > software I've ever seen. The fact is that nobody on the Debian forum was able to help me, or even aware of the existence of that documentation. Or they all was in holiday at that time. Anyway, I did read it but was completely unable to make it to work, whatever I try. It is only when I read Lennart email yesterday, I understand why it was not working: systemd is designed to not work with custom cgroup configurations. The least you could do is to tell that in the documentation. I wasted a few weeks with that. And if it is already stated in the doc that systemd will not work with custom cgroup configurations, you must emphasis more on that issue, so that worried users doesn't miss it, and doesn't waste their time with this. > > > So, don't say me I could have done this or that, that's not my > > point. My major point is GNU/Linux have always been about choices, > > That's not true at all, it's never been about choices. Well, you don't need to say anything more, we just don't have the same conception of Free Software. For me, Free Software is about 5 fundamental liberties, and liberty is all about choices. > > > and the actual systemd implementation and lack of documentation is > > just removing the possibility for the user to choose what he want do > > with the cgroups, which can break the whole system apart when he try > > to do its own cgroup configuration. > > If you wish to use your own cgroup configurations, yes, I would > suggest not using systemd. It is what I have done after formatting and checking my drive. And that's the real problem, systemd is not compatible with custom cgroup configuration. I hope this will change in the future, because this is a choice (again!) I made to use a custom cgroup configuration. And I am sure I am not the only one into a similar case. As an alternative, systemd should at least provide a setup option for it to not interfere with an existing cgroup configuration. > But please work with the kernel cgroup > developers, as the cgroup interface is going to be changing quite a > bit in the future. OK, I will do it. > > This really has nothing to do with systemd on it's
Re: [systemd-devel] systemd and cgroups
On Mon, Jan 13, 2014 at 5:35 PM, Thomas Bächler wrote: > Am 13.01.2014 02:47, schrieb Kay Sievers: >> On Mon, Jan 13, 2014 at 8:07 AM, Greg KH wrote: >>> On Sun, Jan 12, 2014 at 11:48:56PM +0100, Dominique Michel wrote: I need that pc for production, so I rapidly installed another distribution without systemd. So this problem is solved for me, but that doesn't solve that to force any user to use a default configuration without any possibility of user setup, and without documentation that can allow an user to do that, is just a design fault. >>> >>> That sounds like a distro issue, please take this up with your distro >>> developers, this isn't a systemd issue. >> >> http://www.freedesktop.org/wiki/Software/systemd/MyServiceCantGetRealtime/ > > Let me quote from that: > > "By default systemd places all system services into their own control > groups in the "cpu" hierarchy." > > That is not true anymore since systemd 207 IIRC (whenever the whole > cgroup rework started, I might have the version number wrong). In fact, > systemd only puts services into the own cpu control group once you > explicitly set the CPUShares for a service. > > "Instead of evening out CPU per process this will cause CPU to be evened > out per service." > > This benefit has been lost with systemd 207, at least it is not the > default behaviour anymore. Yeah, that will all come back this year, when the new kernel cgroup interfaces are ready. The wiki should still apply to the above mentioned, a bit outdated, version in Debian. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd and cgroups
Am 13.01.2014 02:47, schrieb Kay Sievers: > On Mon, Jan 13, 2014 at 8:07 AM, Greg KH wrote: >> On Sun, Jan 12, 2014 at 11:48:56PM +0100, Dominique Michel wrote: >>> I need that pc for production, so I rapidly installed another >>> distribution without systemd. So this problem is solved for me, but >>> that doesn't solve that to force any user to use a default >>> configuration without any possibility of user setup, and without >>> documentation that can allow an user to do that, is just a design fault. >> >> That sounds like a distro issue, please take this up with your distro >> developers, this isn't a systemd issue. > > http://www.freedesktop.org/wiki/Software/systemd/MyServiceCantGetRealtime/ Let me quote from that: "By default systemd places all system services into their own control groups in the "cpu" hierarchy." That is not true anymore since systemd 207 IIRC (whenever the whole cgroup rework started, I might have the version number wrong). In fact, systemd only puts services into the own cpu control group once you explicitly set the CPUShares for a service. "Instead of evening out CPU per process this will cause CPU to be evened out per service." This benefit has been lost with systemd 207, at least it is not the default behaviour anymore. signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd and cgroups
On Mon, Jan 13, 2014 at 8:07 AM, Greg KH wrote: > On Sun, Jan 12, 2014 at 11:48:56PM +0100, Dominique Michel wrote: >> I need that pc for production, so I rapidly installed another >> distribution without systemd. So this problem is solved for me, but >> that doesn't solve that to force any user to use a default >> configuration without any possibility of user setup, and without >> documentation that can allow an user to do that, is just a design fault. > > That sounds like a distro issue, please take this up with your distro > developers, this isn't a systemd issue. http://www.freedesktop.org/wiki/Software/systemd/MyServiceCantGetRealtime/ Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd and cgroups
On Sun, Jan 12, 2014 at 11:48:56PM +0100, Dominique Michel wrote: > I need that pc for production, so I rapidly installed another > distribution without systemd. So this problem is solved for me, but > that doesn't solve that to force any user to use a default > configuration without any possibility of user setup, and without > documentation that can allow an user to do that, is just a design fault. That sounds like a distro issue, please take this up with your distro developers, this isn't a systemd issue. > Again, the point of the cgroups is to be able to adapt the system to > any kind of workload, and to have systemd that take control of that > good and flexible system, and at the same time, doesn't provide > a way for an user to adapt the default configuration to its own need, > is just a big design bug, which start with Lennart failure to > take in account the fact that all users are corner cases by > definition, because all users are doing different kind of works with > their computers. That's not the goak of cgroups at all, sorry. > Today, during a forum discussion on the cgroups, someone gave > the link above with the different Lennart's statements. I begun to > understand. Later also today, I finally find some documentation on > the freedesktop web site. But that's too late, I need this pc for > production, and I have other things to do than risking a hard disk > failure because of a freezing system, so I will not reinstall > Debian. And for that, I didn't even read more of that doc than a few > lines. I just lost the interest of the good idea that systemd is, that > because of its catastrophic implementation that can cause so severe > regression like system freeze, and its almost complete lack of > documentation. I don't think you have looked, systemd is the best documented piece of software I've ever seen. > So, don't say me I could have done this or that, that's not my point. My > major point is GNU/Linux have always been about choices, That's not true at all, it's never been about choices. > and the actual systemd implementation and lack of documentation is > just removing the possibility for the user to choose what he want do > with the cgroups, which can break the whole system apart when he try > to do its own cgroup configuration. If you wish to use your own cgroup configurations, yes, I would suggest not using systemd. But please work with the kernel cgroup developers, as the cgroup interface is going to be changing quite a bit in the future. This really has nothing to do with systemd on it's own, sorry. Please talk with your distro developers if you are unhappy with their design decisions. best of luck, greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd and cgroups
Le Sun, 12 Jan 2014 11:09:15 -0800, Greg KH a écrit : > On Sun, Jan 12, 2014 at 06:10:34PM +0100, Dominique Michel wrote: > > Last, this systemd patch is more than 3 years old now, and I also > > just found that freedesktop is involved in that mess: > > http://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/ > > > > So, that imply, if I am right with my diagnostic, the next question > > is what can be done to solve that issue? > > I don't see a clear "issue" that you are asking about here, care to > summarize it in a better way? Well, at http://article.gmane.org/gmane.linux.kernel/1063354 "Lennart Poettering: Well, this feature is... completely irrelevant for normal desktop people. ... In fact, I just prepped a patch to systemd to move every service and every user session into its own cgroup in the 'cpu' hierarchy (in addition to the group it already creates in the 'systemd' hierarchy)." Lennart show a total disrespect for the users by thinking his own user case is the only one in the world. More: "So, this patch (the kernel patch) only has an effect of people which build kernels from an xterm with make -j all day, and at the same time want to watch a movie, from a player they also start from a terminal, but from another one." I guess Lennart made a study off all possible combinations of all cgroups with all available GNU/Linux commands lying around in order to make that statement... And he continue: "In fact, I just prepped a patch to systemd to move every service and every user session into its own cgroup in the 'cpu' hierarchy (in addition to the group it already creates in the 'systemd' hierarchy). On a system that runs systemd for both managing users and sessions this means you are already half-way at what you want." He concede this systemd patch is only half of what the kernel can do when correctly used. I left the kernel/user space at side, because this is not the idea to make that control of the cgroups in user space that cause problem but its actual implementation. And next: "Well, if I make behaviour like this default in systemd, then this means there won't be user setup for this. Because the distros shipping systemd will get this as default behaviour." In the kernel, it is other choices than that default, and the combination of these choices and libcgroup made possible to adapt the cgroups to any kind of work load. Which is obviously not the case of a default behaviour without user setup. And never will. I installed Debian it was a few months ago, and during the installation, systemd was installed. My typical work load is to have qjackctl in the autostart of my desktop, which start jackd or jackdbus, and also gladish, as well than to have all my audio applications using real-time priorities. With a few lines into my .asoundrc, I interface the ALSA applications with JACK, that without noticeable added latency, so I just don't need pulse. I also use electronic simulation software like ng-spice, and to get the last version, I compile it. For that reason, I don't want to double boot between some kind of vanilla kernel and a rt kernel, I use the cgroups to get rt priority for the audio. That's explained here: http://trac.jackaudio.org/wiki/Cgroups All I need is one single cgroup with cpu.rt_runtime_us for the audio applications. I succeeded to make that to work on Debian with systemd, and it is here the shit begun. Whatever I try, systemd was insisting to put anything it think is good to have into that rt cgroup, and the result was the same after each boot: after a variable amount of time, the system was so frozen that even the magic keys was dead. On the Debian forum, nobody was able to help me, not even with some pointer on documentation. And normal, because according to Leenart, it is no user setup for the cgroups. I am a normal desktop user that just want to be able, in addition to electronic simulation, libreoffice and stuffs like that, to be able to make some professional audio work with his linux desktop. And thank to systemd default configuration without user setup, it is just not possible any more to do professional audio work for a casual desktop when systemd is installed. I need that pc for production, so I rapidly installed another distribution without systemd. So this problem is solved for me, but that doesn't solve that to force any user to use a default configuration without any possibility of user setup, and without documentation that can allow an user to do that, is just a design fault. Again, the point of the cgroups is to be able to adapt the system to any kind of workload, and to have systemd that take control of that good and flexible system, and at the same time, doesn't provide a way for an user to adapt the default configuration to its own need, is just a big design bug, which start with Lennart failure to take in account the fact that all users are corner cases by definition, because all users are doing different kind of works with their c
Re: [systemd-devel] systemd and cgroups
On Sun, Jan 12, 2014 at 06:10:34PM +0100, Dominique Michel wrote: > Last, this systemd patch is more than 3 years old now, and I also > just found that freedesktop is involved in that mess: > http://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/ > > So, that imply, if I am right with my diagnostic, the next question is > what can be done to solve that issue? I don't see a clear "issue" that you are asking about here, care to summarize it in a better way? thanks, greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd and cgroups
Recently, I experimented with Debian sid, which installed systemd. Systemd idea is nice, but its implementation is a catastrophe. It is more than one year, maybe more than 2, I am using the kernel cgroups on gentoo to get rt scheduling with JACK, that without any trouble. http://trac.jackaudio.org/wiki/Cgroups On that Debian system, this was just impossible, because whatever I try, systemd insisted to put what it think is good to have into the rt cgroup, which soon or later resulted in a complete system freeze with even dead magic keys. After loosing my time a few days with this, I removed Debian and installed gentoo instead. I just found the reason here: http://article.gmane.org/gmane.linux.kernel/1063354 "Lennart Poettering: Well, this feature is... completely irrelevant for normal desktop people. ... In fact, I just pom all otrepped a patch to systemd to move every service and every user session into its own cgroup in the 'cpu' hierarchy (in addition to the group it already creates in the 'systemd' hierarchy)." What terrify me in that story is the total lack of consideration for the needs of who the chief developer of systemd strongly suggest are abnormal desktop users. More, Lennart take one corner use case, compilation at the console, and generalize it to all other corner use cases, which is just impossible to do because a corner case is precisely a case that is different from all other cases, and all desktop users are potentially all a case by themselves. We are all different and each one of us make a different use of its desktop, so we are all, at different levels, corner case users. Last, this systemd patch is more than 3 years old now, and I also just found that freedesktop is involved in that mess: http://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/ So, that imply, if I am right with my diagnostic, the next question is what can be done to solve that issue? Best Regards, Dominique ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Systemd and cgroups
Thanks! KV On Thu, Apr 11, 2013 at 5:37 PM, Kay Sievers wrote: > On Thu, Apr 11, 2013 at 12:46 PM, Kevin Wilson wrote: >> Hello, >> This is a default fedore 18 machine with default kernel. Kernel came >> with the F18 disto, no changes. No special things like LXC/OpenVZ. So >> I guess no 3rd party mount any cgroup. >> >>>then systemd itself will mount all the resource controllers >> that are compiled into the kernel. >> >> How ? >> I don't know of an API to query from userspace which cgroups are built >> in into the kernel. Is there such an API ?! > > /proc/cgroups > >> I will appreciate if someone will point where in systemd code this >> mounting of all built in kernel cgroups controllers is done. >> >> >> I suppose that systemd mount all controllers **without** name=systemd, >> am I right ? because the name=systemd does not appear in any >> controller except /sys/fs/cgroup/systemd (see the initial post in >> this thread). >> >> Is there a way to know whether a mount was done by systemd or not ? > > All that are found are mounted by PID1. > > Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Systemd and cgroups
On Thu, Apr 11, 2013 at 12:46 PM, Kevin Wilson wrote: > Hello, > This is a default fedore 18 machine with default kernel. Kernel came > with the F18 disto, no changes. No special things like LXC/OpenVZ. So > I guess no 3rd party mount any cgroup. > >>then systemd itself will mount all the resource controllers > that are compiled into the kernel. > > How ? > I don't know of an API to query from userspace which cgroups are built > in into the kernel. Is there such an API ?! /proc/cgroups > I will appreciate if someone will point where in systemd code this > mounting of all built in kernel cgroups controllers is done. > > > I suppose that systemd mount all controllers **without** name=systemd, > am I right ? because the name=systemd does not appear in any > controller except /sys/fs/cgroup/systemd (see the initial post in > this thread). > > Is there a way to know whether a mount was done by systemd or not ? All that are found are mounted by PID1. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Systemd and cgroups
Hello, This is a default fedore 18 machine with default kernel. Kernel came with the F18 disto, no changes. No special things like LXC/OpenVZ. So I guess no 3rd party mount any cgroup. >then systemd itself will mount all the resource controllers that are compiled into the kernel. How ? I don't know of an API to query from userspace which cgroups are built in into the kernel. Is there such an API ?! I will appreciate if someone will point where in systemd code this mounting of all built in kernel cgroups controllers is done. I suppose that systemd mount all controllers **without** name=systemd, am I right ? because the name=systemd does not appear in any controller except /sys/fs/cgroup/systemd (see the initial post in this thread). Is there a way to know whether a mount was done by systemd or not ? Sorry for so much questions, I simply try to fully understand. Regards, Kevin On Wed, Apr 10, 2013 at 1:14 PM, Daniel P. Berrange wrote: > On Wed, Apr 10, 2013 at 12:43:56PM +0300, Kevin Wilson wrote: >> Hello, >> I have a question about systemd and cgroups: >> "mount | grep cgroups" shows that only one entry has name=systemd. >> and is mounted on /sys/fs/cgroup/systemd . (see below the full output >> of "mount | grep cgroups" >> >> Is it true that all other cgroup entry shown by "mount | grep cgroups" >> were not mounted by systemd (and may be unmounted without directly >> causing problems is systemd)? > > If some 3rd party application has mounted cgroups controllers before > systemd starts, it will honour that setup. If they were not already > mounted, then systemd itself will mount all the resource controllers > that are compiled into the kernel. > > Systemd will only actually create sub-dirs in those controllers > that are listed in the 'DefaultControllers' setting of systemd.conf, > which defaults to 'cpu'. > > Daniel > -- > |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| > |: http://libvirt.org -o- http://virt-manager.org :| > |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| > |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Systemd and cgroups
On Wed, Apr 10, 2013 at 12:43:56PM +0300, Kevin Wilson wrote: > Hello, > I have a question about systemd and cgroups: > "mount | grep cgroups" shows that only one entry has name=systemd. > and is mounted on /sys/fs/cgroup/systemd . (see below the full output > of "mount | grep cgroups" > > Is it true that all other cgroup entry shown by "mount | grep cgroups" > were not mounted by systemd (and may be unmounted without directly > causing problems is systemd)? If some 3rd party application has mounted cgroups controllers before systemd starts, it will honour that setup. If they were not already mounted, then systemd itself will mount all the resource controllers that are compiled into the kernel. Systemd will only actually create sub-dirs in those controllers that are listed in the 'DefaultControllers' setting of systemd.conf, which defaults to 'cpu'. Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Systemd and cgroups
Hello, I have a question about systemd and cgroups: "mount | grep cgroups" shows that only one entry has name=systemd. and is mounted on /sys/fs/cgroup/systemd . (see below the full output of "mount | grep cgroups" Is it true that all other cgroup entry shown by "mount | grep cgroups" were not mounted by systemd (and may be unmounted without directly causing problems is systemd)? tmpfs on /sys/fs/cgroup type tmpfs (rw,nosuid,nodev,noexec,mode=755) cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd) cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset) cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpuacct,cpu) cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory) cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices) cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer) cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio) cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event) rgs Kevin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
