nspawn: register a scope for the unit if --register=no is specified

[poettering]

Previously, only when --register=yes was set (the default) the invoked
container would get its own scope, created by machined on behalf of
nspawn. With this change if --register=no is set nspawn will still get
its own scope (which is a good thing, so that --slice= and --property=
take effect), but this is not done through machined but by registering a
scope unit directly in PID 1.

Summary:

--register=yes → allocate a new scope through machined (the default)
--register=yes --keep-unit → use the unit we are already running in an register with machined
--register=no → allocate a new scope directly, but no machined
--register=no --keep-unit → do not allocate nor register anything

Fixes: #5823

[keszybz]

Hm…

$ sudo systemd-nspawn --register=no --link-journal=try-guest -U -M rawhidex -b --bind /home 
Spawning container rawhidex on /var/lib/machines/rawhidex.
Press ^] three times within 1s to kill container.
Selected user namespace base 1499201536 and range 65536.
systemd 233 running in system mode. (+PAM +AUDIT +SELINUX -IMA -APPARMOR -SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP -GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN default-hierarchy=hybrid)
Detected virtualization systemd-nspawn.
Detected architecture x86-64.

Welcome to Fedora 27 (Rawhide)!

Failed to create /../../../../machine.slice/rawhidex.scope/init.scope control group: No such file or directory
Failed to allocate manager object: No such file or directory
[!!!!!!] Failed to allocate manager object, freezing.
Freezing execution.

[keszybz]

So, it seems systemd-233 has hard time running with --register=no (this is on legacy hierarchy btw). If I run without -b, the shell that is launched sees the following:

$ sudo systemd-nspawn --register=no --link-journal=try-guest -U -M rawhidex --bind /home                           
Spawning container rawhidex on /var/lib/machines/rawhidex.
Press ^] three times within 1s to kill container.
Selected user namespace base 1499201536 and range 65536.
-bash-4.4# cat /sys/fs/cgroup/unified/cgroup.procs 
0
0
0
0
0
0
0
0
0
0
0
0
0
-bash-4.4# cat /sys/fs/cgroup/systemd/cgroup.procs 
-bash-4.4# echo $$
1
-bash-4.4# cat /proc/$$/cgroup
11:perf_event:/
10:memory:/machine.slice/rawhidex.scope
9:pids:/../../../machine.slice/rawhidex.scope
8:hugetlb:/
7:cpu,cpuacct:/machine.slice/rawhidex.scope
6:cpuset:/
5:net_cls,net_prio:/
4:blkio:/machine.slice/rawhidex.scope
3:devices:/../machine.slice/rawhidex.scope
2:freezer:/
1:name=systemd:/../../../../machine.slice/rawhidex.scope
0::/../../../../machine.slice/rawhidex.scope

wtf?

[keszybz]

With --register=yes:

-bash-4.4# cat /proc/$$/cgroup
11:perf_event:/
10:memory:/
9:pids:/
8:hugetlb:/
7:cpu,cpuacct:/
6:cpuset:/
5:net_cls,net_prio:/
4:blkio:/
3:devices:/
2:freezer:/
1:name=systemd:/
0::/

[poettering]

well, if you want to run systemd inside a container you need to delegate write access to its own cgroup subtree to it. Hence basically nspawn needs to register its own scope or it needs to run in a service that has Delegate=yes set. It's one of the reasons for this patch: I wanted to make sure that we always have a scope around, except if you acknowledge you set up your own, with --keep-unit

[keszybz]

OK, let's merge then. Maybe we can detect this case better and warn about it, but this shouldn't hold up merging since it fixes a real issue.