(Work In Progress)
Some things about systemd aren't necessarily bad, they're just damned Ugly.
If you define
After=network.target in a Unit file, that means nothing to systemd. And certainly does not mean what you would be likely to expect it to mean:
network.target has very little meaning during start-up. It only indicates that the network management stack is up after it has been reached. Whether any network interfaces are already configured when it is reached is undefined. It's [sic] primary purpose is for ordering things properly at shutdown: since the shutdown ordering of units in systemd is the reverse of the startup ordering, any unit that is order After=network.target can be sure that it is stopped before the network is shut down if the system is powered off.
The fix? Use both
Wants= on the
network-online.target (as opposed to
network.target). Of course!
systemctl contains a
systemctl list-dependencies --after gdm.service
However, this lists all things that contain an "After: gdm-service" in their definition, not the things that are after gdm.service in the dependencies tree.
So it actually shows the things that start before gdm.service, not after it. (similarly “--before” shows those that start after gdm, not before it)
systemctl show sshd shows the settings of sshd. These come from the
/lib/systemd/system/sshd.service file, merged with the default system-wide settings. That's fair enough, I am sure you will agree. Quite useful, in fact.
If you try
systemctl show SomeServiceNameIJustMadeUp, it will show the default settings, even though there is no such service. It won't tell you there's no such service, it will just plough on and let you wallow in your misconception that it is a valid service. Thanks, systemd.
Systemd internally stores times (such as
TimeoutStartUSec) in microseconds. However, you have to give it values in whole seconds. So you specify
TimeoutStartSec, and it shows you
TimeoutStartUSec. Which is not confusing enough for the designers of systemd, so it doesn't show the value of
TimeoutStartUSec in microseconds, but in seconds:
[root@fedora26 system]# grep Timeout foo.service TimeoutStartSec=3 [root@fedora26 system]# systemctl show foo|grep Timeout TimeoutStartUSec=3s
If you choose to specify
TimeoutStartUSec yourself, that is invalid, gets ignored, and is replaced by the default value of "1min 30s":
[root@fedora26 system]# grep Timeout foo.service TimeoutStartUSec=3s [root@fedora26 system]# systemctl show foo|grep Timeout TimeoutStartUSec=1min 30s
And finally, there is the glaring inconsistency that
TimeoutStartUSec=1min 30s is a text value, not a number of seconds or of microseconds.
According to Bug 2047, this is on purpose, in the name of "friendliness". Thank you, systemd.
None of this is at all helpful for troubleshooting, whether scripted or otherwise.
There's always more ...