On Mi, 04.04.18 23:19, Jeff Solomon (jsolomon8...@gmail.com) wrote: > Hi, > > On the CentOS7 AWS with the following systemd installed: > > systemd-219-42.el7_4.4.x86_64 > > Any loginctl command that we try to run at boot time (during the AWS "user > data" section of cloud-init), will hang and then timeout. > > The same loginctl command run after you ssh into the box and become root, > works fine. > > I can currently get around this problem by running: > > systemd-run loginctl .... > > which implies that something about the boot time execution environment > doesn't allow loginctl to run. > > When I strace the hanging command, I can see that it's waiting on > /run/dbus/system_bus_socket. > > I don't think I have a unit ordering problem because systemd-run is able to > run the command. It must be the environment. > > Sorry for what must be a dumb question, but what is different about the > execution environment at boot time that is preventing loginctl from running?
loginctl is a client tool for systemd-logind, the communicatoin between both happens through dbus, hence both are client to dbus-daemon. Both systemd-logind and dbus-daemon are run during late boot (i.e. are ordered after basic.target). systemd-logind is bus activated, and dbus-daemon is socket activated, which means that as soon as dbus-daemon's socket unit is up (i.e. dbus.socket is started) any client (such as loginctl) connecting to it will implicitly wait first for dbus-daemon to be fully started, and then until logind to be fully started. Now, if you invoke loginctl from something that itself delays the boot process, then you might create a deadlock: you are waiting for dbus.service/systemd-logind.service to start-up but are at the same time blocking it from being started. Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
