Re: Transitioning scripts relying on libcgroup-tools to the cgroup’s unified hierarchy (v2)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> On 12/05/2020 14:13, Petr Pisar wrote:
> ...
> 
>  On Tue, May 12, 2020 at 12:47:51PM +0000, virgo wrote:
> >> I recommend you to ask the question about v2 support on Fedora Bugzilla
> >> for=
> >> 
> >>   the
> >> 
> >> libcgroup package
> 
> <https://bugzilla.redhat.com/buglist.cgi?classification=3DFedora&compo...
> 
> >> =3Dlibcgroup&product=3DFedora&query_format=3Dadvanced>.
> > 
> > Prior to the top post, I went through the Bugzilla tickets, with these
> > parameters:
> > 
> > * component=libcgroup
> > * order=changeddate DESC
> > * product=Fedora
> > * query_format=advanced
> > 
> > and the hits dating back to 2015[fn:1] were just a dozen, none making
> > mention
> > of v2. So, I am not sure whether opening feature requests would help.
>  
>  Fedora uses systemd that enforces cgroup v2. If libcgroup package is not
>  compatible with cgroup v2, then libcgroup package is not compatible with
>  Fedora and this is a bug and should be reported to the Fedora's Bugzilla.
> 
> That's not really true. Fedora now defaults to v2 but you can still
> choose to boot to v1 instead and systemd still supports both.
Yes, that is well documented. I am not desperate to the point of fiddling with 
kernel boot options, though.
> 
> > By the way, what would you and (and others) recommend as a
> 
> replacement for
> 
> > libcgroup-tools?[fn:2]
>  
>  No idea. I don't use cgroups for anything on purpose. As far as I know,
>  cgroups membership in Fedora is defined by systemd's logind. Whether it
>  suits
>  your needs, I have no idea. I also think it's possible to manage the
>  membership manually by editing files in cgroup2 pseudo file system.
> 
> Yes as I understand it you're not supposed to fiddle with cgroups
> manually, you're supposed to use systemd-run or something and let
> systemd do the necessary.
> 
> It would probably help if the original user described what his goal
> was rather than the low level details of how he achieved that with
> cgroups v1.
Let’s say I want to compile `pandoc` with modifications of my own and many non-
default compiler options. At the same time, on the same machine, I still want 
to do other stuff. `cgexec` et al. helped a lot to cap the memory and CPU usage 
of tasks like that, without needing container and virtual machines setups. 
Nowadays, I am into `systemd-nspawn` because it requires minimal configuration 
from my end. It is still a hammer deployed to kill an ant. In pages like 
`systemd.resource-control(5)`, one can read:

    See the New Control Group Interfaces[1] for an introduction on how to 
**make use of resource control APIs from programs.**

Great! But I do not know how to make programs consuming those APIs. The tools 
talked about in this thread helped a lot and I am searching for replacement 
that would fit with my low-proficiency in Devops.

That said, I read somewhere about user units, I am under the impression those 
would help. Somewhere on my computer, there already many tools to accomplish 
all of I need and beyond, the issue is that I have not yet met documentation 
dumbed down enough to make me see the light.
> 
> Tom
> 
> --
> Tom Hughes (tom(a)compton.nu)
> http://compton.nu/
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux