On Thu, 12.06.14 17:20, Cedric Bosdonnat (cbosdon...@suse.com) wrote:
Hi all,
(replying to your original mail, I did see your later patch, but I
thought to focus on the background of the patch)
In libvirt lxc driver's use of machined, the CreateMachine call is sent
out before the init process is actually started. This gives libvirt lxc
driver some time to setup the container before starting it.
Not following here... What time is meant there?
The idea is that CreateMachine is either invoked from the child when the
system is fully set up, right before droppping privs. Or that it is
invoked from the parent at that point.
You need some kind of synchronization when invoking CreateMachine, you
shouldn't allow this to race freely against each other. Among other
reasons this becomes really problematic as soon as you use the devices
cgroup controller, as then CreateMachine() might take away device access
(including the ability to mknod() specific device nodes). This means you
need to populate /dev for the container before invoking CreateMachine,
but then you also need to make sure CreateMachine is complete before you
invoke your container userspace...
However, the leader PID sent isn't the proper one and functions like
machinectl login are failing. Would it be possible to add an API to
update the Leader PID of a machine after its creation?
Hmm, why isn't the right leader PID set? Not following?
Our other solution would be to start the init process and send it to
sleep to be able to continue setting up the container... but that means
costly (and maybe fragile) refactoring.
Well, you have to fork, set up things, then tell the parent you are
ready to get cgroupified, then wait for that to be complete, then exec()
your real userspace. I don't think thre's a real way around that in the
long run...
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
