Hide Forgot
>> We are having issues with it since it is it's own mount >> namespace. We >> noticed in Fedora it is running in the hosts namespace, and has a >> comment in the file. >> >> >> # Note that machined cannot be placed in a mount namespace, since it >> # needs access to the host's mount namespace in order to implement >> the >> # "machinectl bind" operation. >> >> >> When running with docker and oci-register-machine, we are seeing some >> strange patterns, and since it is in its own mount namespace, the >> unshare is triggering some >> issue with the RHEL kernel and docker. >> We want to use oci-register-machine in Docker/Runc. But that communicates with systemd-machined which triggers a leak, which leads to docker hitting a kernel bug. We are removing oci-register-machine for now, but updating this unit file to match fedora would clean up a lot of leaks.
Related bugs. https://bugzilla.redhat.com/show_bug.cgi?id=1357121 https://bugzilla.redhat.com/show_bug.cgi?id=1347821
I guess we could make systemd-machined unit file look the same as it does on Fedora. But, would that really help? I read discussions under related bugs and it seems to me that problem you face is generic and not at all related to systemd-machined. Even if we change the unit file and systemd-machined is running in host's mount namespace. It still takes only single service on a system having PrivateTmp=yes or simple unshare -m bash in some user script and we are back in trouble. Note that I am not strongly against this change if you prove to me that it will *really* fix your problem. So far I am not convinced it will.
Yes we understand that this is still a problem. We are just trying to mitigate the main cause of the issue. We are working the issue on many fronts. But this one seemed to be low hanging fruit, and the way systemd-machined was going in the long run anyways.
Quality Engineering Management has reviewed and declined this request. You may appeal this decision by reopening this request.