Comment # 20 on bug 1069711 from Oliver Kurz

http://lord.arch/tests/409#downloads gives more details in the logs that were
uploaded while the salt call is blocked.

salt-minion reports:

```
Jan 30 11:40:24 susetest systemd[1]: Starting The Salt Minion...
Jan 30 11:40:27 susetest systemd[1]: Started The Salt Minion.
Jan 30 11:40:50 susetest salt-minion[4782]: [ERROR   ] The Salt Master has
cached the public key for this node, this salt minion will wait for 10 seconds
before attempting to re-authenticate
Jan 30 11:41:00 susetest salt-minion[4782]: [ERROR   ] The Salt Master has
cached the public key for this node, this salt minion will wait for 10 seconds
before attempting to re-authenticate
```

salt-master reports:

```
-- Logs begin at Tue 2018-01-30 11:29:48 EST, end at Tue 2018-01-30 11:46:14
EST. --
Jan 30 11:40:08 susetest systemd[1]: Starting The Salt Master Server...
Jan 30 11:40:13 susetest systemd[1]: Started The Salt Master Server.
```

so nothing that looks suspicious.

When I look in the full journal though I can find

```
Jan 30 11:40:06 susetest systemd[1]: Started Hostname Service.
Jan 30 11:40:08 susetest systemd[1]: Starting The Salt Master Server...
Jan 30 11:40:13 susetest systemd[1]: Started The Salt Master Server.
Jan 30 11:40:24 susetest systemd[1]: Starting The Salt Minion...
Jan 30 11:40:27 susetest systemd[1]: Started The Salt Minion.
Jan 30 11:40:50 susetest salt-minion[4782]: [ERROR   ] The Salt Master has
cached the public key for this node, this salt minion will wait for 10 seconds
before attempting to re-authenticate
Jan 30 11:41:00 susetest salt-minion[4782]: [ERROR   ] The Salt Master has
cached the public key for this node, this salt minion will wait for 10 seconds
before attempting to re-authenticate
Jan 30 11:41:05 susetest org.opensuse.Snapper[784]: terminate called after
throwing an instance of
'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::lock_error>
>'
Jan 30 11:41:05 susetest org.opensuse.Snapper[784]:   what():  boost: mutex
lock failed in pthread_mutex_lock: Invalid argument
Jan 30 11:41:05 susetest systemd[1]: Created slice
system-systemd\x2dcoredump.slice.
Jan 30 11:41:05 susetest systemd[1]: Started Process Core Dump (PID 5288/UID
0).
Jan 30 11:41:06 susetest systemd-coredump[5289]: Process 3736 (snapperd) of
user 0 dumped core.
Jan 30 11:41:10 susetest dbus-daemon[784]: [system] Activating via systemd:
service name='org.freedesktop.hostname1'
unit='dbus-org.freedesktop.hostname1.service' requested by ':1.28' (uid=473
pid=1879 comm="/usr/bin/gnome-shell ")
Jan 30 11:41:10 susetest systemd[1]: Starting Hostname Service...
Jan 30 11:41:10 susetest dbus-daemon[784]: [system] Successfully activated
service 'org.freedesktop.hostname1'
Jan 30 11:41:10 susetest systemd[1]: Started Hostname Service.
Jan 30 11:43:18 susetest dbus-daemon[784]: [system] Activating via systemd:
service name='org.freedesktop.hostname1'
unit='dbus-org.freedesktop.hostname1.service' requested by ':1.28' (uid=473
pid=1879 comm="/usr/bin/gnome-shell ")
Jan 30 11:43:18 susetest systemd[1]: Starting Hostname Service...
Jan 30 11:43:18 susetest dbus-daemon[784]: [system] Successfully activated
service 'org.freedesktop.hostname1'
Jan 30 11:43:18 susetest systemd[1]: Started Hostname Service.
```

So at first snapper dies and then the hostname service is started after salt is
trying to start. Is this a coincidence in this one special job or happening in
other cases as well? Yes, reproduced in reruns. In any case, even after killing
all snapper processes I can not get salt to work.

@mihai, you can now login remotely over VNC and check yourself: `vncviewer
-Shared lord.arch:6000`