Am 09.02.20 um 02:24 schrieb Ryutaroh Matsumoto: > Control: tags -1 + fixed - moreinfo > Control: retitle -1 Fix found: systemd-sysusers hangs if nis is > enabled in a systemd-nspawn container > > I found a solution (or a workaround). > > The problem is that > (1) systemd-sysusers tries to use Sun RPC (TCP connection to 127.0.0.1:111) > in a nis enabled container.
To be more speficic, it's not systemd-sysusers directly, but the nis NSS module which appears to access the rpcbind socket. > (2) at that time, rpcbind.socket is ready (by systemd), and I guess this is actually a timinig issue and you seem to hit this condition that rpcbind.socket is already started in the container but not on the physical system. > (3) rpcbind.service is not ready, because rpcbind.service depends on > systemd-sysusers.service. More specifically, rpcbind.service has After=systemd-tmpfiles-setup.service and systemd-tmpfiles-setup.service has After=systemd-sysusers.service So the dependency chain is like this rpcbind.service->systemd-tmpfiles-setup.service->systemd-sysusers.service > (4) Then systemd-sysusers communication to 127.0.0.1:111 get stuck. > > When I made > > [Unit] > Before=rpcbind.socket > as /etc/systemd/system/systemd-sysusers.service.d/my.conf > > OR > > [Unit] > After=systemd-sysusers.service > as /etc/systemd/system/rpcbind.socket.d/my.conf > > Then the problem goes away!!! > > Anyway, the current dependency > rpcbind.socket -> systemd-sysusers.service -> rpcbind.service > looks nonsense. > > The remaining problem is where the above nonsense order of > dependency should be fixed, rpcbind Debian package or the systemd > upstream... Not sure what the right solution is. One might be, that the nis NSS module handles this situation (rpcbind.socket running, rpcbind.service not running) better, or that rpcbind.socket changes its ordering to avoid this situation. I do think this should be fixed on the nis/rpcbind side though.
signature.asc
Description: OpenPGP digital signature