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