On Fri, 24.04.15 12:37, Jonathan Boulle (jonathanbou...@gmail.com) wrote: > Naive question, perhaps, but why does systemd even need to umount when > being run in a mount namespace? Can't we let the kernel tear them down when > it exits?
Well, so far our intention there was to ensure that the codepaths we use inside a container and on bare-metal are as as close as possible, and only deviate where there's really no other sensible way. I mean, let's not forget that nspawn originally was created as a testing ground for our pid 1 code, so that we didn't have to physically reboot all the time just to test it. Hence: unless there's a really good reason to do something different inside a container than on the host we will always opt for the same codepaths. (Also, if there's some code that readlly needs to be different inside a container, we'll try to avoid conditionalizing on the fact wether things are in a container or not, but much rather on the actual feature that is missing/different in a container, for example a missing capability or such) > > > When rkt is started with --debug, the systemd logs are printed. When rkt > > > is started without --debug, systemd is started with --log-target=null in > > > order to mute the logs. > > > > That generally sounds a bit extreme... > > do you have another suggestion? :-) Log the output but redirect it somewhere useful so that the user can look at it if he wants, but so that it isn't shown all the time? Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
