[cycloptic]

>It's not like nspawn just calls into the service manager to get things done on its behalf via dbus or something like that.

Yes, it literally does? https://github.com/systemd/systemd/blob/master/src/nspawn/ns...

Additionally there is a lot of shared functionality in libsystemd. Take a look at the rest of the code in nspawn and see how little it actually accomplishes.

[newnewpdro]

> Yes, it literally does? https://github.com/systemd/systemd/blob/master/src/nspawn/ns...

No, it literally doesn't. That's just registration with the service manager, and it's optional. Basically it's to make the service manager aware of nspawn's actions, when it's on a systemd host.

I already pointed out they share a lot of code. The service manager process doesn't do squat on behalf of nspawn.

[cycloptic]

It doesn't matter that it's optional and you could use some other service manager. The minimal amount of stuff it does is not really that useful without registering with a service/container manager. Of course it doesn't have to be systemd and machinectl, but anything else would have to implement the same dbus interface if it wanted to work the intended way. My point is that nspawn would not have been written if it couldn't piggyback on this work that was already done. Otherwise all you have is a cgroup, some firewall rules and some mounts in a random folder, which as demonstrated here recently, can just be done with a small bash script.