Hacker's ramblings

Something funny happened to my Fedora 20 installation. Stuff that used to work stopped doing so. I understand, that I'm dealing with "bleeding edge" Linux-distro, but it kind of starts to annoy me, when things don't get back like they were.

Here is one:

# systemctl status iscsi.service --all
iscsi.service - Login and scanning of iSCSI devices
   Loaded: loaded (/usr/lib/systemd/system/iscsi.service; enabled)
   Active: inactive (dead)
           start condition failed at Thu 2014-07-17 12:23:18 EEST; 1min 24s ago
           none of the trigger conditions were met
     Docs: man:iscsid(8)
           man:iscsiadm(8)

Jul 17 12:23:17 box systemd[1]: Started Login and scanning of iSCSI devices.
Jul 17 12:23:18 box systemd[1]: Started Login and scanning of iSCSI devices.

Aow come on! "none of the trigger conditions were met"!! I don't know what changed with the precious trigger conditions. Basic checks didn't reveal anything noteworthy:

# systemctl is-active iscsi.service
active
# systemctl list-dependencies iscsi.service
iscsi.service

There are some other people suffering from the same issue. Fedora 20 ypbind won’t start at boot. NIS logins unavailable immediately after boot (ypbind service NOT started). and Bug 1027114 - nfs mount fails during boot because network is not ready point me to the direction of service trying to start too early. There is a document explaining how to run services only after network is up (Running Services After the Network is up), but the point is: somebody goofed! This used to work.

I tried a classic off/on -trick:

# systemctl disable iscsi.service
# systemctl enable iscsi.service

... no avail. Still after a boot I have a list of failing services:

# systemctl --failed
UNIT             LOAD   ACTIVE SUB    DESCRIPTION
arpwatch.service loaded failed failed Arpwatch daemon which keeps track of ether
dhcpd.service    loaded failed failed DHCPv4 Server Daemon
iscsi.service    loaded failed failed Login and scanning of iSCSI devices

LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB    = The low-level unit activation state, values depend on unit type.

3 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.

Finally I chose to add the After=network-online.target -line to my service description. First the service description needs to be copied from /usr/lib/systemd/system/ into /etc/systemd/system/. The rule is very simple: don't edit files under /usr/ and it applies also here. Systemd has a built in fall-back mechanism. If your own tailor made file doesn't exist in /etc/, it will take the default one. It is good to have that, but better if no such tinkering wasn't needed at all. What if there is an update to the service-description? I have to manually update my copied file.

So, I did a:

# cd /etc/systemd/system/
# cp /usr/lib/systemd/system/iscsi.service .

and edited the file. I added one line to Unit-description:

[Unit]
After=network-online.target

To be absolutely clear: I didn't touch the other lines.

Since systemd doesn't pick up the changes very easily, I did a:

# systemctl disable iscsi.service
# systemctl enable iscsi.service

after status informed, that my change was in place:

# systemctl status iscsi
iscsi.service - Login and scanning of iSCSI devices
   Loaded: loaded (/etc/systemd/system/iscsi.service; enabled)

Notice how, the service description is now under /etc/.

Anyway, that did the trick for all of my failing services. Now they start nicely on bootup.