4 ms·
>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://git
by cycloptic 7y ago
>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/nspawn-register.c 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 7y ago> Yes, it literally does? https://github.com/systemd/systemd/blob/master/src/nspawn/nspawn-register.c 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 7y agoIt 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.