When I use a word, it means just what I choose it to mean — neither more nor less.

Tip 1: disabling services

The single most trivial, yet most famously irritating problem with systemd involves the meaning of the words disable and mask. In systemd, a disabled service can still run, only a masked service is actually disabled. To well and truly stop a service named (for example) furshlugginer, you'd want to do something like:

systemctl stop furshlugginer.service
systemctl disable furshlugginer.service
systemctl mask furshlugginer.service

If you really want to be sure to drive a stake through it's heart, then you could also try:

yum erase `rpm -q -f /usr/lib/systemd/system/furshlugginer.service`

But that might try to take most of the system with it if the dependencies are intertwingled enough.

Tip 2: listing services

You might be wondering where chkconfig --list disappeared to. What you want with systemd is:

systemctl --full list-unit-files

That's a pretty big list, so you might want to use grep to cut it down by searching for words like enabled in the output.

Tip 3: binary log files

If you think binary log files are a hideously bad idea, you still can't get rid of the journald component of systemd, but you can turn it into nothing more than a relay that sends the logs to rsyslogd where they can be written in human readable form and examined without any esoteric tools required (especially in a recovery session after booting from a live cd).

If you don't think binary log files are a bad idea, you should watch the infinite reboot loop you get when the binary files are corrupted :-).

Step 1: Edit /etc/systemd/journald.conf and set Storage=none and ForwardToSyslog=yes

Step 2: If you don't already have rsyslog installed, yum install rsyslog

Step 3: [Ignore this for fedora 26] Create the file /etc/rsyslog.d/sd-socket.conf which contains the line:
$AddUnixListenSocket /run/systemd/journal/syslog

GAH! [Ignore this for fedora 26] In fedora 22 you need more changes to make this work: In /etc/rsyslogd.conf you need to uncomment the line for $ModLoad imuxsock, and I'm not sure but you may also need to uncomment the $SystemLogSocketName /run/systemd/journal/syslog line.

GAH! GAH! In fedora 26 they have switched rsyslog to use the new and improved syntax (designed, I suspect, to get syslog users to sign up with the project sponsor for support contracts). Now you need to change /etc/rsyslog.conf to have these changes near the top:

module(load="imuxsock"    # provides support for local system logging (e.g. via logger command)
       SysSock.Name="/run/systemd/journal/syslog")  # read from socket
#       SysSock.Use="off") # Turn off message reception via local log socket; 
                          # local messages are retrieved through imjournal now.
#module(load="imjournal"            # provides access to the systemd journal
#       StateFile="imjournal.state") # File to store the position in the journal

Basically, provide the proper socket name for the imuxsock module (instead of turning off the socket) and comment out the no longer needed imjournal module.

Step 4: Reboot.

Now logs will wind up only in the normal text files where the sane expect to find them. you can remove the old binary log clutter:

rm -rf /var/log/journal

Aside from improving human readability, if your system shuts down badly (like from a power failure because some other systemd bug hung at shutdown and you had to power cycle to get the system back :-), I've had corrupted binary logs cause the system to hang at boot as the journal tries to interpret the random gibberish in the binary files. With text files you might get some gibberish too, but all rsyslogd does is append to the file. It doesn't need the old log data to be pristine to survive.

I have more tips and rants over in Beating Systemd Into Submission.

Anyway, that's all my useful tips, time to dissolve into the ranting systemd usually brings on...

ranting...

One of the funniest pages on the web is The Biggest Myths page defending practically everything that is wrong with systemd by simply denying it is a problem.

For instantance, myth #1 that systemd is monolithic is denied by presenting evidence that the source code builds 69 programs, so it can't be monolithic. The fact that the systemd daemon itself has grown to the size of The White Whale and subsumed the function of a dozen separate older daemons doesn't mean it is monolithic, oh no, it comes with 68 other binaries, so it clearly isn't monolithic. The pyramids aren't monolithic either because they were made from lots of individual blocks. The memory use indicator growing bigger and bigger on a totally idle system every time a new update to systemd is released is merely coincidence.

Of course my favorite myth is #22 "systemd is not scriptable". If systemd was so flexible and scriptable, it would be trivially easy to keep it away from my NFS mounts of test systems that go up and down all the time which I don't want to spend hours timing out on. But systemd is so bloody "helpful" that even if you leave the NFS mount out of the fstab, it will sieze control of it so it can "helpfully" shut it down cleanly if you reboot. I've examined the source. This behavior is hard coded. With the old sysv init scripts, you could go in and make them background the unmount commands. With systemd, you are going to spend hours timing out on NFS mounts, and there isn't a damn script you can write to change it.

Then there is #24 "systemd is unstable and buggy" where they prove it isn't buggy because "We are pretty good in keeping systemd out of the list of blocker bugs". Well, of course, if your sponsor, promoter, and fanboys are in charge of voting on blockers, you won't get any bugs in the blocker bug list :-).