Limiting users ram with cgroups not working (for me)












3















I registred because I didn't manage running cgroups with several tutorials/comments/whatever you find on google. I want to limit the amount of ram a specifix user may use. Internet says "cgroups". My testserver is running Ubuntu 14.04. You can divide the mentioned tutorials in two categories. Directly set limits using echo and use specific config. Neither is working for me.



Setting Limits using echo



cgcreate -g cpu,cpuacct,...:/my_group


finishes without any notices. When I try to run



echo 100M > memory.limit_in_bytes


it just says "not permitted" even when using sudo. I don't even reach any point of limiting another user.



Setting limits using config



I read about two config files. So here are my config files:



cgconfig.conf



mount {
memory = /cgroup/memory;
}

group limit_grp {
memory {
memory.limit_in_bytes=100M;
memory.memsw.limit_in_bytes=125M;
}
}


cgrules.conf



testuser    memory    limit_grp


When I run



cgconfigparser -l /etc/cgconfig.conf


it mounts to systemd. Now I log on with testuser, run an memory intense task - and it runs without caring about my limit.



I tried rebooting, nothing changed. Even some strange attempts using kernel config didn't work. I'm new to cgroups and didn't expect it to be that complicated. I'd appreciate any suggestions to my topic. Thank you in advance!










share|improve this question























  • Could you be more specific when you say "mounts to systemd"? You mentioned this was on Ubuntu 14.04, which is not running systemd (but has some related patches).

    – Mark Stosberg
    Jun 25 '16 at 22:15











  • It's easy to misunderstand (and hence misapply) redirection with sudo, too.

    – JdeBP
    Jun 27 '16 at 14:39











  • I can either add cgroups to /etc/fstab (which will lead to 'failed to parse config') or don't add it at first and pase config. Both fstab and parsing lead to following output in mount: "systemd on /sys/fs/cgroup/systemd type cgroup (rw,noexec,nosuid,nodev,none,name=systemd)"

    – darkspirit510
    Jun 27 '16 at 16:31


















3















I registred because I didn't manage running cgroups with several tutorials/comments/whatever you find on google. I want to limit the amount of ram a specifix user may use. Internet says "cgroups". My testserver is running Ubuntu 14.04. You can divide the mentioned tutorials in two categories. Directly set limits using echo and use specific config. Neither is working for me.



Setting Limits using echo



cgcreate -g cpu,cpuacct,...:/my_group


finishes without any notices. When I try to run



echo 100M > memory.limit_in_bytes


it just says "not permitted" even when using sudo. I don't even reach any point of limiting another user.



Setting limits using config



I read about two config files. So here are my config files:



cgconfig.conf



mount {
memory = /cgroup/memory;
}

group limit_grp {
memory {
memory.limit_in_bytes=100M;
memory.memsw.limit_in_bytes=125M;
}
}


cgrules.conf



testuser    memory    limit_grp


When I run



cgconfigparser -l /etc/cgconfig.conf


it mounts to systemd. Now I log on with testuser, run an memory intense task - and it runs without caring about my limit.



I tried rebooting, nothing changed. Even some strange attempts using kernel config didn't work. I'm new to cgroups and didn't expect it to be that complicated. I'd appreciate any suggestions to my topic. Thank you in advance!










share|improve this question























  • Could you be more specific when you say "mounts to systemd"? You mentioned this was on Ubuntu 14.04, which is not running systemd (but has some related patches).

    – Mark Stosberg
    Jun 25 '16 at 22:15











  • It's easy to misunderstand (and hence misapply) redirection with sudo, too.

    – JdeBP
    Jun 27 '16 at 14:39











  • I can either add cgroups to /etc/fstab (which will lead to 'failed to parse config') or don't add it at first and pase config. Both fstab and parsing lead to following output in mount: "systemd on /sys/fs/cgroup/systemd type cgroup (rw,noexec,nosuid,nodev,none,name=systemd)"

    – darkspirit510
    Jun 27 '16 at 16:31
















3












3








3








I registred because I didn't manage running cgroups with several tutorials/comments/whatever you find on google. I want to limit the amount of ram a specifix user may use. Internet says "cgroups". My testserver is running Ubuntu 14.04. You can divide the mentioned tutorials in two categories. Directly set limits using echo and use specific config. Neither is working for me.



Setting Limits using echo



cgcreate -g cpu,cpuacct,...:/my_group


finishes without any notices. When I try to run



echo 100M > memory.limit_in_bytes


it just says "not permitted" even when using sudo. I don't even reach any point of limiting another user.



Setting limits using config



I read about two config files. So here are my config files:



cgconfig.conf



mount {
memory = /cgroup/memory;
}

group limit_grp {
memory {
memory.limit_in_bytes=100M;
memory.memsw.limit_in_bytes=125M;
}
}


cgrules.conf



testuser    memory    limit_grp


When I run



cgconfigparser -l /etc/cgconfig.conf


it mounts to systemd. Now I log on with testuser, run an memory intense task - and it runs without caring about my limit.



I tried rebooting, nothing changed. Even some strange attempts using kernel config didn't work. I'm new to cgroups and didn't expect it to be that complicated. I'd appreciate any suggestions to my topic. Thank you in advance!










share|improve this question














I registred because I didn't manage running cgroups with several tutorials/comments/whatever you find on google. I want to limit the amount of ram a specifix user may use. Internet says "cgroups". My testserver is running Ubuntu 14.04. You can divide the mentioned tutorials in two categories. Directly set limits using echo and use specific config. Neither is working for me.



Setting Limits using echo



cgcreate -g cpu,cpuacct,...:/my_group


finishes without any notices. When I try to run



echo 100M > memory.limit_in_bytes


it just says "not permitted" even when using sudo. I don't even reach any point of limiting another user.



Setting limits using config



I read about two config files. So here are my config files:



cgconfig.conf



mount {
memory = /cgroup/memory;
}

group limit_grp {
memory {
memory.limit_in_bytes=100M;
memory.memsw.limit_in_bytes=125M;
}
}


cgrules.conf



testuser    memory    limit_grp


When I run



cgconfigparser -l /etc/cgconfig.conf


it mounts to systemd. Now I log on with testuser, run an memory intense task - and it runs without caring about my limit.



I tried rebooting, nothing changed. Even some strange attempts using kernel config didn't work. I'm new to cgroups and didn't expect it to be that complicated. I'd appreciate any suggestions to my topic. Thank you in advance!







ubuntu systemd limit ram cgroups






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked Jun 25 '16 at 17:47









darkspirit510darkspirit510

163




163













  • Could you be more specific when you say "mounts to systemd"? You mentioned this was on Ubuntu 14.04, which is not running systemd (but has some related patches).

    – Mark Stosberg
    Jun 25 '16 at 22:15











  • It's easy to misunderstand (and hence misapply) redirection with sudo, too.

    – JdeBP
    Jun 27 '16 at 14:39











  • I can either add cgroups to /etc/fstab (which will lead to 'failed to parse config') or don't add it at first and pase config. Both fstab and parsing lead to following output in mount: "systemd on /sys/fs/cgroup/systemd type cgroup (rw,noexec,nosuid,nodev,none,name=systemd)"

    – darkspirit510
    Jun 27 '16 at 16:31





















  • Could you be more specific when you say "mounts to systemd"? You mentioned this was on Ubuntu 14.04, which is not running systemd (but has some related patches).

    – Mark Stosberg
    Jun 25 '16 at 22:15











  • It's easy to misunderstand (and hence misapply) redirection with sudo, too.

    – JdeBP
    Jun 27 '16 at 14:39











  • I can either add cgroups to /etc/fstab (which will lead to 'failed to parse config') or don't add it at first and pase config. Both fstab and parsing lead to following output in mount: "systemd on /sys/fs/cgroup/systemd type cgroup (rw,noexec,nosuid,nodev,none,name=systemd)"

    – darkspirit510
    Jun 27 '16 at 16:31



















Could you be more specific when you say "mounts to systemd"? You mentioned this was on Ubuntu 14.04, which is not running systemd (but has some related patches).

– Mark Stosberg
Jun 25 '16 at 22:15





Could you be more specific when you say "mounts to systemd"? You mentioned this was on Ubuntu 14.04, which is not running systemd (but has some related patches).

– Mark Stosberg
Jun 25 '16 at 22:15













It's easy to misunderstand (and hence misapply) redirection with sudo, too.

– JdeBP
Jun 27 '16 at 14:39





It's easy to misunderstand (and hence misapply) redirection with sudo, too.

– JdeBP
Jun 27 '16 at 14:39













I can either add cgroups to /etc/fstab (which will lead to 'failed to parse config') or don't add it at first and pase config. Both fstab and parsing lead to following output in mount: "systemd on /sys/fs/cgroup/systemd type cgroup (rw,noexec,nosuid,nodev,none,name=systemd)"

– darkspirit510
Jun 27 '16 at 16:31







I can either add cgroups to /etc/fstab (which will lead to 'failed to parse config') or don't add it at first and pase config. Both fstab and parsing lead to following output in mount: "systemd on /sys/fs/cgroup/systemd type cgroup (rw,noexec,nosuid,nodev,none,name=systemd)"

– darkspirit510
Jun 27 '16 at 16:31












2 Answers
2






active

oldest

votes


















0














The reason you're seeing this behaviour is probably due to the fact that your login session already has a memory limit group associated, and the process is inheriting that, according to systemd configuration.



Check your running process cgroup with:



cat /proc/pid/cgroup


...and you may see something like:



13:name=systemd:/user/0.user/2.session
12:debug:/
11:pids:/
10:net_prio:/user/0.user/2.session
9:perf_event:/user/0.user/2.session
8:net_cls:/user/0.user/2.session
7:freezer:/user/0.user/2.session
6:devices:/user/0.user/2.session
5:memory:/user/0.user/2.session
4:blkio:/user/0.user/2.session
3:cpuacct:/user/0.user/2.session
2:cpu:/
1:cpuset:/


Assuming you don't want this behavior, you can use your custom cgroup with memory controller editing /etc/systemd/logind.conf and removing memory from the Controllers line.






share|improve this answer

































    0














    I had a similar problem (on Fedora 29, though): It seemed that my /etc/cgconfig.conf was completely ignored. Running



    sudo systemctl enable cgconfig


    and rebooting solved the problem.






    share|improve this answer








    New contributor




    Samuel Gruetter is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
    Check out our Code of Conduct.




















      Your Answer








      StackExchange.ready(function() {
      var channelOptions = {
      tags: "".split(" "),
      id: "106"
      };
      initTagRenderer("".split(" "), "".split(" "), channelOptions);

      StackExchange.using("externalEditor", function() {
      // Have to fire editor after snippets, if snippets enabled
      if (StackExchange.settings.snippets.snippetsEnabled) {
      StackExchange.using("snippets", function() {
      createEditor();
      });
      }
      else {
      createEditor();
      }
      });

      function createEditor() {
      StackExchange.prepareEditor({
      heartbeatType: 'answer',
      autoActivateHeartbeat: false,
      convertImagesToLinks: false,
      noModals: true,
      showLowRepImageUploadWarning: true,
      reputationToPostImages: null,
      bindNavPrevention: true,
      postfix: "",
      imageUploader: {
      brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
      contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
      allowUrls: true
      },
      onDemand: true,
      discardSelector: ".discard-answer"
      ,immediatelyShowMarkdownHelp:true
      });


      }
      });














      draft saved

      draft discarded


















      StackExchange.ready(
      function () {
      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f292097%2flimiting-users-ram-with-cgroups-not-working-for-me%23new-answer', 'question_page');
      }
      );

      Post as a guest















      Required, but never shown

























      2 Answers
      2






      active

      oldest

      votes








      2 Answers
      2






      active

      oldest

      votes









      active

      oldest

      votes






      active

      oldest

      votes









      0














      The reason you're seeing this behaviour is probably due to the fact that your login session already has a memory limit group associated, and the process is inheriting that, according to systemd configuration.



      Check your running process cgroup with:



      cat /proc/pid/cgroup


      ...and you may see something like:



      13:name=systemd:/user/0.user/2.session
      12:debug:/
      11:pids:/
      10:net_prio:/user/0.user/2.session
      9:perf_event:/user/0.user/2.session
      8:net_cls:/user/0.user/2.session
      7:freezer:/user/0.user/2.session
      6:devices:/user/0.user/2.session
      5:memory:/user/0.user/2.session
      4:blkio:/user/0.user/2.session
      3:cpuacct:/user/0.user/2.session
      2:cpu:/
      1:cpuset:/


      Assuming you don't want this behavior, you can use your custom cgroup with memory controller editing /etc/systemd/logind.conf and removing memory from the Controllers line.






      share|improve this answer






























        0














        The reason you're seeing this behaviour is probably due to the fact that your login session already has a memory limit group associated, and the process is inheriting that, according to systemd configuration.



        Check your running process cgroup with:



        cat /proc/pid/cgroup


        ...and you may see something like:



        13:name=systemd:/user/0.user/2.session
        12:debug:/
        11:pids:/
        10:net_prio:/user/0.user/2.session
        9:perf_event:/user/0.user/2.session
        8:net_cls:/user/0.user/2.session
        7:freezer:/user/0.user/2.session
        6:devices:/user/0.user/2.session
        5:memory:/user/0.user/2.session
        4:blkio:/user/0.user/2.session
        3:cpuacct:/user/0.user/2.session
        2:cpu:/
        1:cpuset:/


        Assuming you don't want this behavior, you can use your custom cgroup with memory controller editing /etc/systemd/logind.conf and removing memory from the Controllers line.






        share|improve this answer




























          0












          0








          0







          The reason you're seeing this behaviour is probably due to the fact that your login session already has a memory limit group associated, and the process is inheriting that, according to systemd configuration.



          Check your running process cgroup with:



          cat /proc/pid/cgroup


          ...and you may see something like:



          13:name=systemd:/user/0.user/2.session
          12:debug:/
          11:pids:/
          10:net_prio:/user/0.user/2.session
          9:perf_event:/user/0.user/2.session
          8:net_cls:/user/0.user/2.session
          7:freezer:/user/0.user/2.session
          6:devices:/user/0.user/2.session
          5:memory:/user/0.user/2.session
          4:blkio:/user/0.user/2.session
          3:cpuacct:/user/0.user/2.session
          2:cpu:/
          1:cpuset:/


          Assuming you don't want this behavior, you can use your custom cgroup with memory controller editing /etc/systemd/logind.conf and removing memory from the Controllers line.






          share|improve this answer















          The reason you're seeing this behaviour is probably due to the fact that your login session already has a memory limit group associated, and the process is inheriting that, according to systemd configuration.



          Check your running process cgroup with:



          cat /proc/pid/cgroup


          ...and you may see something like:



          13:name=systemd:/user/0.user/2.session
          12:debug:/
          11:pids:/
          10:net_prio:/user/0.user/2.session
          9:perf_event:/user/0.user/2.session
          8:net_cls:/user/0.user/2.session
          7:freezer:/user/0.user/2.session
          6:devices:/user/0.user/2.session
          5:memory:/user/0.user/2.session
          4:blkio:/user/0.user/2.session
          3:cpuacct:/user/0.user/2.session
          2:cpu:/
          1:cpuset:/


          Assuming you don't want this behavior, you can use your custom cgroup with memory controller editing /etc/systemd/logind.conf and removing memory from the Controllers line.







          share|improve this answer














          share|improve this answer



          share|improve this answer








          edited Jun 12 '17 at 14:46









          Kusalananda

          131k17250410




          131k17250410










          answered Jun 12 '17 at 13:56









          St0rMSt0rM

          1013




          1013

























              0














              I had a similar problem (on Fedora 29, though): It seemed that my /etc/cgconfig.conf was completely ignored. Running



              sudo systemctl enable cgconfig


              and rebooting solved the problem.






              share|improve this answer








              New contributor




              Samuel Gruetter is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
              Check out our Code of Conduct.

























                0














                I had a similar problem (on Fedora 29, though): It seemed that my /etc/cgconfig.conf was completely ignored. Running



                sudo systemctl enable cgconfig


                and rebooting solved the problem.






                share|improve this answer








                New contributor




                Samuel Gruetter is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                Check out our Code of Conduct.























                  0












                  0








                  0







                  I had a similar problem (on Fedora 29, though): It seemed that my /etc/cgconfig.conf was completely ignored. Running



                  sudo systemctl enable cgconfig


                  and rebooting solved the problem.






                  share|improve this answer








                  New contributor




                  Samuel Gruetter is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                  Check out our Code of Conduct.










                  I had a similar problem (on Fedora 29, though): It seemed that my /etc/cgconfig.conf was completely ignored. Running



                  sudo systemctl enable cgconfig


                  and rebooting solved the problem.







                  share|improve this answer








                  New contributor




                  Samuel Gruetter is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                  Check out our Code of Conduct.









                  share|improve this answer



                  share|improve this answer






                  New contributor




                  Samuel Gruetter is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                  Check out our Code of Conduct.









                  answered 25 mins ago









                  Samuel GruetterSamuel Gruetter

                  101




                  101




                  New contributor




                  Samuel Gruetter is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                  Check out our Code of Conduct.





                  New contributor





                  Samuel Gruetter is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                  Check out our Code of Conduct.






                  Samuel Gruetter is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                  Check out our Code of Conduct.






























                      draft saved

                      draft discarded




















































                      Thanks for contributing an answer to Unix & Linux Stack Exchange!


                      • Please be sure to answer the question. Provide details and share your research!

                      But avoid



                      • Asking for help, clarification, or responding to other answers.

                      • Making statements based on opinion; back them up with references or personal experience.


                      To learn more, see our tips on writing great answers.




                      draft saved


                      draft discarded














                      StackExchange.ready(
                      function () {
                      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f292097%2flimiting-users-ram-with-cgroups-not-working-for-me%23new-answer', 'question_page');
                      }
                      );

                      Post as a guest















                      Required, but never shown





















































                      Required, but never shown














                      Required, but never shown












                      Required, but never shown







                      Required, but never shown

































                      Required, but never shown














                      Required, but never shown












                      Required, but never shown







                      Required, but never shown







                      Popular posts from this blog

                      CARDNET

                      Boot-repair Failure: Unable to locate package grub-common:i386

                      濃尾地震