A patch below, functionally identical to my previous. But this seems
neater, showing the intent more clearly: clearer that this is a "true"
bug in systemd.
Cheers, Paul
--
Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics University
Dear Martin,
You can create a drop-in like
/etc/systemd/system/cgred.service.d/delegate.conf
with
[Service]
Delegate=yes
I tried that, but did not help; also did not help to do similar with
file named
/etc/systemd/system/cgrulesengd.service.d/delegate.conf
matching name of running daemon.
Hello Paul,
Paul Szabo [2017-07-21 18:25 +1000]:
> Where would I set that? My cgrulesengd (from package cgroup-tools) is
> started from /etc/init.d/cgred, not from some systemd *.service thing.
You can create a drop-in like /etc/systemd/system/cgred.service.d/delegate.conf
with
[Service]
Dear Martin,
... the official and documented mechanism is to set
"Delegate=yes" in a unit which wants to do its own cgroup management.
Everything else is just a hack prone to bitrotting...
Where would I set that? My cgrulesengd (from package cgroup-tools) is
started from /etc/init.d/cgred,
Hello all,
Paul Szabo [2017-07-21 13:07 +1000]:
> Now updating my machines to stretch, I see this issue is still present,
It's an uphill battle indeed - the official and documented mechanism is to set
"Delegate=yes" in a unit which wants to do its own cgroup management.
Everything else is just a
Now updating my machines to stretch, I see this issue is still present,
now in systemd version 232-25. The same steps can reproduce:
- Set up cgroups e.g. adding TaskIDs to /sys/fs/cgroup/cpu/DIR/tasks
files. (I use cgrulesengd from package cgroup-tools, but any other
use of cgroups is
Package: systemd
Version: 215-17+deb8u4
Followup-For: Bug #803013
Dear Maintainer,
It seems that an option Delegate=yes was introduced upstream, but
this does not seem to be available in Jessie. The current mode of
operation for systemd is to destroy all the cgroup subtree of a
service in e.g.
Processing commands for cont...@bugs.debian.org:
> tags 803013 - fixed-upstream
Bug #803013 [systemd] systemd should not destroy application created cgroups
Removed tag(s) fixed-upstream.
> usertags 803013 - status-closed
User is paul.sz...@sydney.edu.au
There were no usertags set.
Us
Dear Julian,
Thank you for the various pointers.
> You set Delegate=yes for the unit ...
That does not seem available yet in jessie.
> The kernel cgroups implementation moved or is moving to a
> single-writer, single-hierarchy implementation ...
It does not seem to have moved yet in jessie.
On Fri, Nov 13, 2015 at 11:36:30AM +1100, paul.sz...@sydney.edu.au wrote:
> Progress? For my efforts upstream, I got the comment:
>
> > Sorry, but systemd implements a single-writer cgroup logic (as
> > requested by the kernel maintainers), and hence takes possesion of the
> > whole tree. ...
>
On Fri, Nov 13, 2015 at 12:50:57PM +0100, Julian Andres Klode wrote:
> On Fri, Nov 13, 2015 at 11:36:30AM +1100, paul.sz...@sydney.edu.au wrote:
> > Progress? For my efforts upstream, I got the comment:
> >
> > > Sorry, but systemd implements a single-writer cgroup logic (as
> > > requested by
Control: severity -1 important
Hi
Am 12.11.2015 um 22:21 schrieb paul.sz...@sydney.edu.au:
> severity 803013 critical
> tag 803013 - moreinfo unreproducible + confirmed
> thanks
>
> Dear Michael,
>
> You did not reply for a week, so I am trying to set tags myself.
>
> Also, while doing this,
Processing commands for cont...@bugs.debian.org:
> severity 803013 critical
Bug #803013 [systemd] systemd should not destroy application created cgroups
Severity set to 'critical' from 'important'
> tag 803013 - moreinfo unreproducible + confirmed
Bug #803013 [systemd] systemd should not d
severity 803013 critical
tag 803013 - moreinfo unreproducible + confirmed
thanks
Dear Michael,
You did not reply for a week, so I am trying to set tags myself.
Also, while doing this, am trying to set severity back to "critical":
this bug does break unrelated software.
---
For the record: the
Am 12.11.2015 um 22:29 schrieb Michael Biebl:
> I would suggest that you raise this upstream at
> https://github.com/systemd/issues/new, as it is not really Debian specific.
Sorry, wrong URL:
https://github.com/systemd/systemd/issues/new
--
Why is it that all of the instruments seeking
Progress? For my efforts upstream, I got the comment:
> Sorry, but systemd implements a single-writer cgroup logic (as
> requested by the kernel maintainers), and hence takes possesion of the
> whole tree. ...
I observe it only uses the /sys/fs/cgroup/systemd tree.
(I wonder about the "req by
Dear Michael,
This bug is easily reproducible in a permitted and supported
(if somewhat non-default) configuration: please remove the
moreinfo unreproducible
tags.
I wonder whether the patch suggested here solves also the issue in
http://bugs.debian.org/777601
and the in-progress fix in file
Am 2015-11-07 04:22, schrieb paul.sz...@sydney.edu.au:
Dear Michael,
I wonder how that line came to be missed on my machines ...
If you restore the previous state and you ran
dpkg-reconfigure libpam-runtime, what do you get?
Running
dpkg-reconfigure libpam-runtime
asks me nicely:
PAM
Dear Michael,
>> Running
>> dpkg-reconfigure libpam-runtime
>> asks me nicely ...
>> There is no indication that I should, or must, select "do systemd".
>
> The default should be, that all those 3 are selected. So definitely
> something odd.
Am I allowed to choose other than default? Are such
Dear Michael,
I wonder how that line came to be missed on my machines ...
> If you restore the previous state and you ran
> dpkg-reconfigure libpam-runtime, what do you get?
Running
dpkg-reconfigure libpam-runtime
asks me nicely:
PAM configuration
Pluggable Authentication Modules
Am 05.11.2015 um 05:11 schrieb paul.sz...@sydney.edu.au:
> I wonder how that line came to be missed on my machines: I upgraded from
> wheezy (which was upgraded from previous releases).
If that line was not automatically added it probably means you had made
custom modifications to the file in
Dear Michael,
>> I wonder how that line came to be missed on my machines: I upgraded from
>> wheezy (which was upgraded from previous releases).
>
> If that line was not automatically added it probably means you had made
> custom modifications to the file in the past.
Possible, but unlikely: the
Dear Michael,
> I'm not able to reproduce the issue either.
> ... this looks like something specific to your system configuration, a
> default jessie system doesn't seem to be affected.
I found what causes reproducibility: editing the file
/etc/pam.d/common-session
and removing or commenting
paul.sz...@sydney.edu.au [2015-10-29 21:46 +1100]:
> # Set things up
> mkdir /sys/fs/cgroup/cpu/mytest
> echo $$ > /sys/fs/cgroup/cpu/mytest/tasks
> # Check it is there
> grep . /sys/fs/cgroup/cpu/mytest/tasks
> # Do the systemd thing
> systemctl daemon-reload
> systemctl start
Dear Martin,
[Sorry I should have added...]
> This actually sounds similar to https://bugs.debian.org/777601, but
> this already got fixed in 215-12, thus in Jessie.
... and 777601 sounds like
https://bugzilla.redhat.com/show_bug.cgi?id=1139223
but then
Dear Martin,
>> # Set things up
>> mkdir /sys/fs/cgroup/cpu/mytest
>> echo $$ > /sys/fs/cgroup/cpu/mytest/tasks
>> # Check it is there
>> grep . /sys/fs/cgroup/cpu/mytest/tasks
>> # Do the systemd thing
>> systemctl daemon-reload
>> systemctl start anacron
>> # See it gone
>>
Dear Michael,
>>> Please test if this issue is still reproducible with 227 ...
>> Sorry ... not easily enough ...
> Or create a throw-away VM using sid. That's what I would use.
Could do; or do on a throw-away partition; either way it takes hours,
not minutes. I presume you have an "unstable"
paul.sz...@sydney.edu.au [2015-10-29 21:46 +1100]:
> Could do; or do on a throw-away partition; either way it takes hours,
> not minutes. I presume you have an "unstable" machine handy. Then you
> can test in seconds (as root):
>
> # Set things up
> mkdir /sys/fs/cgroup/cpu/mytest
> echo $$
Processing control commands:
> tags -1 moreinfo unreproducible
Bug #803013 [systemd] systemd should not destroy application created cgroups
Added tag(s) unreproducible and moreinfo.
--
803013: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=803013
Debian Bug Tracking System
Contact
Control: tags -1 moreinfo unreproducible
Am 29.10.2015 um 20:16 schrieb paul.sz...@sydney.edu.au:
>>> # Set things up
>>> mkdir /sys/fs/cgroup/cpu/mytest
>>> echo $$ > /sys/fs/cgroup/cpu/mytest/tasks
>>> # Check it is there
>>> grep . /sys/fs/cgroup/cpu/mytest/tasks
>>> # Do the
Dear Michael,
> I couldn't quite follow what you try to achieve here. I.e. which
> processes or services you want to confine and why. And what exactly
> you did.
> Would be great if you can be a bit more verbose on that.
I am using cgrulesengd from package cgroup-tools to group each user's
Am 29.10.2015 um 02:46 schrieb paul.sz...@sydney.edu.au:
>> Please test if this issue is still reproducible with 227 from unstable
>> and if so, file the issue at https://github.com/systemd/systemd/issues.
>
> Sorry I do not think I can do that, not easily enough: I do not think I
> can install
Processing control commands:
> severity -1 important
Bug #803013 [systemd] systemd should not destroy application created cgroups
Severity set to 'important' from 'critical'
--
803013: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=803013
Debian Bug Tracking System
Contact
Control: severity -1 important
Hi Paul,
thanks for your bug report.
Am 26.10.2015 um 03:12 schrieb Paul Szabo:
> Package: systemd
> Version: 215-17+deb8u2
> Severity: critical
> Tags: patch
> Justification: breaks unrelated software
>
> If you use cgroups, then systemd will on occasions
Package: systemd
Version: 215-17+deb8u2
Severity: critical
Tags: patch
Justification: breaks unrelated software
If you use cgroups, then systemd will on occasions destroy your
settings. To reproduce:
- Set up cgroups e.g. adding TaskIDs to /sys/fs/cgroup/cpu/DIR/tasks
files. (I use
35 matches
Mail list logo
