Thanks Lennart, I hear what you're saying but I'm still confused.
I can run any commands in the "User Data" section. And when I run
"systemctl" immediately prior to attempting to run loginctl (which hangs),
I see the following (snipped):
active running D-Bus System Message Bus
active running D-Bus System Message Bus Socket
active running Login Service
which makes me think that even though cloud-init and these two services all
run after basic.target, the two needed to loginctl to run successfully are
Additionally, the following command works:
systemd-run loginctl ...
I understand what you're saying about dead-lock, but when I run
systemd-run, all I'm really doing is changing the execution environment,
not the flow of my entire script, and loginctl works in that case.
I guess I still don't understand how your explanation makes sense given the
behavior I observe.
Post by Jeff Solomon Post by Jeff Solomon
Any loginctl command that we try to run at boot time (during the AWS
Post by Jeff Solomon
data" section of cloud-init), will hang and then timeout.
The same loginctl command run after you ssh into the box and become root,
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
I don't think I have a unit ordering problem because systemd-run is able
Post by Jeff Solomon
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
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
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 Poettering, Red Hat