loginctl hangs when run at boot time

[lennart@xxxxxxxxxxxxxx (Lennart Poettering)]

On Mi, 04.04.18 23:19, Jeff Solomon (jsolomon8080 at 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