Description of problem: I guess this warrants some discussion but I've come to the conclusion after testing/poking slices and scopes that we should always create machine slice unit/scope ( with some reasonable default resource limits ) when we run systemd-nspawn with the -M, --machine= parameters. If there is any reason why we should not do this by default I would love to hear it. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
So the more I poke slices the more I come to the conclusion that we should automatically create slice units for administrators as opposed to having them creating maintaining and keep tap on those units themselves but rather have them manage it through some tool ( like the proposed controlctl ). And never assign higher level cgroup option on anything but slices ( atleast not manually ) as in not down to unit type service level. /sys/fs/cgroup/ `-- systemd |-- machine.slice <alter resources here> | `-- machine-f20.scope | |-- application.slice <alter resources here> | | |--httpd.service <not here> | |-- system.slice <alter resources here> | | |-- console-getty.service <not here> | | |-- systemd-journald.service <not here> | | | `-- user.slice <alter resources here> |--application.slice <alter resources here> | |-- ntpd.service <not here> |-- system.slice <alter resources here> | |-- systemd-journald.service <not here> | |-- systemd-udevd.service <not here> | | `-- user.slice <alter resources here> |-- user-1000.slice <alter resources here> | |-- systemd-user <not here> | | |-- firefox.service <not here>
Not following. Can you elaborate please? What exactly are you asking for?
Basically administrator should not have to manually create units for OS containers. ( or there would be a switch that does that for them when they start they container )
But each machine gets a scope unit anyway, automatically. So what else do you need?
(In reply to Lennart Poettering from comment #4) > But each machine gets a scope unit anyway, automatically. So what else do > you need? But scope unit is not something you manually alter nor is permanent is it? So let's say I want to assign or alter resources to the OS container and I assume there would be 2 ways of doing that 1. via command 2. by manually editing the unit for the OS container. What I'm talking about here is automatically create the unit in step 2 which he he can later alter manually.
(In reply to Jóhann B. Guðmundsson from comment #5) > (In reply to Lennart Poettering from comment #4) > > But each machine gets a scope unit anyway, automatically. So what else do > > you need? > > But scope unit is not something you manually alter nor is permanent is it? Sure, we will read static config drop-ins, and it is fine to alter it at runtime. > So let's say I want to assign or alter resources to the OS container and I > assume there would be 2 ways of doing that 1. via command 2. by manually > editing the unit for the OS container. systemctl set-property should have the same effect as dropping in a unit file .d snippet. > What I'm talking about here is automatically create the unit in step 2 which > he he can later alter manually. Well, for scopes you won't get a unit file, but you will get drop-ins.
Anyway, I am pretty sure scopes already are good enough for what you want to do, and if they aren't we should fix that, hence closing this bug.