<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>Hey Lennart,</div><div><br></div><div>Thanks for the clarification.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Feb 12, 2019 at 2:17 AM Lennart Poettering <<a href="mailto:lennart@poettering.net">lennart@poettering.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mo, 11.02.19 16:39, Filipe Brandenburger (<a href="mailto:filbranden@google.com" target="_blank">filbranden@google.com</a>) wrote:<br>> Before systemd v237 (when Delegate= was no longer allowed on slice<br>
> units)... Did setting Delegate=yes on a slice have *any* effect at all?<br>
><br>
> Or did it just do nothing (and a slice with Delegate=no or no setting<br>
> behave just the same)?<br>
><br>
> Reason I ask is: I want to scrap this code<br>
> <<a href="https://github.com/opencontainers/runc/blob/v1.0.0-rc6/libcontainer/cgroups/systemd/apply_systemd.go#L195" rel="noreferrer" target="_blank">https://github.com/opencontainers/runc/blob/v1.0.0-rc6/libcontainer/cgroups/systemd/apply_systemd.go#L195</a>><br>
> in libcontainer that tries to detect whether Delegate= is accepted in a<br>
> slice unit. (I'll just default it to false, never try it.)<br>
><br>
> I'd like to be able to say that Delegate=yes never really did anything at<br>
> all on slice units... So I'm trying to confirm that is really the case<br>
> before stating it.<br>
<br>
So, it wasn't supposed to do anything, and what it does differs on<br>
cgroupsv2 and cgroupsv1. </blockquote><div><br></div><div>libcontainer is pretty much cgroupv1 only, so that's what I'm concerned about.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">The fact it wasn't refused outright was an<br>
accident, and because it was one I am not entirely sure what the<br>
precise effect of allowing it was. However, I am pretty sure it at<br>
least had two effects:<br>
<br>
1. it would turn on all controllers for the cgroup<br></blockquote><div><br></div><div>I don't <i>think</i> this is why libcontainer was trying to enable it, since a few lines down it's explicitly enabling all the controllers by setting MemoryAccounting, CPUAccounting and BlockIOAccounting during transient unit creation:</div><div><a href="https://github.com/opencontainers/runc/blob/v1.0.0-rc6/libcontainer/cgroups/systemd/apply_systemd.go#L275">https://github.com/opencontainers/runc/blob/v1.0.0-rc6/libcontainer/cgroups/systemd/apply_systemd.go#L275</a><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">2. it would stop systemd to ever migrating foreign processes below<br>
   that slice, which is primarily relevant only when changing cgroup<br>
   related props on the slice dynamically I guess.<br></blockquote><div><br></div><div>I'm not sure I follow... Do you mean if libcontainer would write to memory.limit_in_bytes (or one of the other properties of the memory or other controller managed by systemd, such as cpu), then systemd would not end up overwriting this as it does some other operation on the cgroup?</div><div><br></div><div>I'm not completely sure I understand what "migrate foreign processes" means, given slices don't really hold any pids directly... Do you mean to scope and service units below that slice?</div><div><br></div><div>In any case, for now I'll probably leave that alone... Though as I revamp libcontainer support for unified hierarchy, I'll try to skip that check on that case, that might make this a legacy-only setting, so not that important to fully get rid of it for a while...</div><div><br></div><div>Cheers!</div><div>Filipe</div><div><br></div></div></div></div></div></div>