[newnewpdro]

> nspawn is a pretty small wrapper around functionality that already existed. It turns out containers are not really that special compared to services, and most of the plumbing was already there in the service manager anyway.

That's more than a little misleading. It's not like nspawn just calls into the service manager to get things done on its behalf via dbus or something like that.

If that were the case, rkt would only have worked on systemd hosts, since it used nspawn to setup its containers.

While it's true nspawn shares a bunch of code in common with the service manager, being in the same repository, it's a substantial program on its own and can function entirely independent of the service manager.

There was a time when nspawn actively required running on a systemd-booted host, but it was completely unnecessary and that check was removed while rkt was being developed. [0]

It's not some thin little ergonomic wrapper around existing service manager facilities.

[0] https://github.com/systemd/systemd/commit/4f923a1984476de344...

[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.