<div dir="ltr"><div><div><div><div><div><div><div>Thanks Lennart, I hear what you're saying but I'm still confused.<br><br></div>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):<br>    <br>    dbus.service                  <wbr>                              <wbr>  loaded active     running         D-Bus System Message Bus<br>    dbus.socket                   <wbr>                               loaded active     running         D-Bus System Message Bus Socket<br>    systemd-logind.service        <wbr>                           loaded active     running         Login Service<br><br></div>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 already running.<br><br></div>Additionally, the following command works:<br><br></div>    systemd-run loginctl ...<br></div><br></div>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.<br><br></div>I guess I still don't understand how your explanation makes sense given the behavior I observe.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 5, 2018 at 1:42 AM, Lennart Poettering <span dir="ltr"><<a href="mailto:lennart@poettering.net" target="_blank">lennart@poettering.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Mi, 04.04.18 23:19, Jeff Solomon (<a href="mailto:jsolomon8080@gmail.com">jsolomon8080@gmail.com</a>) wrote:<br>
<br>
> Hi,<br>
><br>
> On the CentOS7 AWS with the following systemd installed:<br>
><br>
>     systemd-219-42.el7_4.4.x86_64<br>
><br>
> Any loginctl command that we try to run at boot time (during the AWS "user<br>
> data" section of cloud-init), will hang and then timeout.<br>
><br>
> The same loginctl command run after you ssh into the box and become root,<br>
> works fine.<br>
><br>
> I can currently get around this problem by running:<br>
><br>
>     systemd-run loginctl ....<br>
><br>
> which implies that something about the boot time execution environment<br>
> doesn't allow loginctl to run.<br>
><br>
> When I strace the hanging command, I can see that it's waiting on<br>
> /run/dbus/system_bus_socket.<br>
><br>
> I don't think I have a unit ordering problem because systemd-run is able to<br>
> run the command. It must be the environment.<br>
><br>
> Sorry for what must be a dumb question, but what is different about the<br>
> execution environment at boot time that is preventing loginctl from running?<br>
<br>
</span>loginctl is a client tool for systemd-logind, the communicatoin<br>
between both happens through dbus, hence both are client to<br>
dbus-daemon. Both systemd-logind and dbus-daemon are run during late<br>
boot (i.e. are ordered after basic.target). systemd-logind is bus<br>
activated, and dbus-daemon is socket activated, which means that as<br>
soon as dbus-daemon's socket unit is up (i.e. dbus.socket is started)<br>
any client (such as loginctl) connecting to it will implicitly wait<br>
first for dbus-daemon to be fully started, and then until logind to be<br>
fully started.<br>
<br>
Now, if you invoke loginctl from something that itself delays the boot<br>
process, then you might create a deadlock: you are waiting for<br>
dbus.service/systemd-logind.<wbr>service to start-up but are at the same<br>
time blocking it from being started.<br>
<span class="HOEnZb"><font color="#888888"><br>
Lennart<br>
<br>
--<br>
Lennart Poettering, Red Hat<br>
</font></span></blockquote></div><br></div>