[systemd-devel] Antw: [EXT] Re: Moving a service from one systemd slice to another..

[Ulrich Windl]

>>> Lennart Poettering <lennart at poettering.net> schrieb am 06.05.2020 um 17:16
in
Nachricht
<19374_1588778203_5EB2D4DB_19374_121_1_20200506151636.GL89018 at gardel-login>:
> On Mo, 04.05.20 11:52, nitish nagesh (nagesh.nitish at gmail.com) wrote:
> 
>> Hello,
>>
>>    We have this odd want to move a daemon between different systemd
slices.
>> Not sure if that's even a valid thing to do, but here is the
>> requirement.
> 
> The Linux kernel gets a bit confused with accounting if you migrate
> running processes between cgroups. One usually shouldn't do that
> except when forking off/execing new stuff.

IMHO Linux should either handle the case correctly, or forbid it.

> 
>>    The daemon while booting up belongs to a systemd slice (say X) which
has
>> parameters like startupCPUShares tuned to bring the system up faster.
>> However for normal operations after bootup, it would be apt to make it
>> belong to another slice (say Y) with different cgroup parameters
>> configurations (ex: CPUShares). The set of daemons that belong to X and Y
>> are totally different, except for this one daemon. Also the cgroup
>> parameter that are set via slice Y are totally different than those set
via
>> slice X.
> 
> This is not supported. In systemd you can migrate services between
> slices only by stopping them and starting them again.
> 
>>   A few basic questions:
>> ‑ Can a daemon be a part of 2 slices?
> 
> no.
> 
>> ‑ If yes, going by the example above, if slice X loads first followed by
>> slice Y, does it mean when slice X is in force this daemon will have
>> startUpCPUShares set & when slice Y is loaded the CPUShares will be
>> set?
> 
> I don't grok this, sorry.
> 
>>    Please suggest if there are alternate ways in systemd to handle this
>> requirement.
> 
> We don't support that. Slice assignments are sticky during service
> runtime.
> 
> Lennart
> 
> ‑‑
> Lennart Poettering, Berlin
> _______________________________________________
> systemd‑devel mailing list
> systemd‑devel at lists.freedesktop.org 
> https://lists.freedesktop.org/mailman/listinfo/systemd‑devel