I tweeted:

Oh. The reason my office workstation always took a somewhat unusually long time to (re)boot is that I had an ancient, nonexistent iSCSI target configured, so finding all disk devices had to wait for the iSCSI connection attempt to time out. That was silly.

This turns out to not quite be the case. While my ancient iSCSI target configuration had been there for a very long time, I only installed the iSCSI initiator programs recently, on September 4th, when I seem to have installed a bunch of QEMU-related packages. The dependencies pulled in the Fedora iSCSI initiator package, and that package decided that it should enable itself by default.

(Specifically it enabled the iscsi.service unit, which attempts to automatically login to all suitably configured iSCSI targets. Also, I'm not sure my diagnosis in the tweet is correct, although I saw it delaying the boot in general; I just jumped to that explanation when I made the tweet.)

What this experience taught me is that it's a good idea to go look at what boot-time things are enabled every so often, to spot new ones that I don't want. On Fedora, clearly a certain number of things feel free to activate themselves on install, on the assumption that they're harmless (I may disagree). Checking for this every so often is a good idea.

I think that the easiest and most official way is to go look for recently changed things in /etc/systemd/system and important .wants subdirectories of this, especially multi-user.target.wants and sockets.target.wants. Conveniently, enabling units creates symlinks and the modification time of those symlinks is when the unit was enabled. A quick 'ls -lt' will thus turn up any recent new activations.

On the one hand, this feels sort of like a hack. On the other hand, it's a perfectly good Unix way of answering this question in a system where state is represented in the filesystem in straightforward ways. There's no need to provide an API and a command and so on when existing Unix tools can already answer the question perfectly well.

Now that I've stubbed my toe on this, I'm going to see if I can remember to check for new boot-time services every so often. I've already turned up one surprise on my office workstation, where sssd.service got enabled on August 8th (which was when I upgraded the machine from Fedora 27 to Fedora 28, although this didn't happen on my home machine when I upgraded it). This is probably harmless, so I've let it be so far.

(Since the iSCSI stuff has only been there for a month or so, it's not the long term cause of my slower than expected boots (although it may have been delaying them lately). But that's a discussion for another entry.)

PS: This isn't specific to systemd, of course. Any init system is subject to having new or updated packages decide that they absolutely should be enabled. Systemd does give you a somewhat richer set of paths to this due to socket activation, and any dependency-based system can hide extra activations because they can happen concurrently and not obviously delay your boot (most of the time).