Systemd Philosophy.

From my understanding, Systemd was created to make the maintenance of Linux distributions easier.

With previous init systems, you had to know all packages that could interact with a given subsystem, and you had to know them for each distribution for the same subsystem.

For subsystems as complicated as NFS, it was certainly a real pain.

At the same time, Systemd came with added features solving several problems of previous init systems:

• dynamic dependencies management,
• parallel execution of initial processes making boot faster,
• xinetd replacement through socket-activation,
• respawn of services as needed,
• declarative configuration files instead of complicated scripts,
• powerful customization of service configuration files,
• etc.

Concerning Unix philosophy, gurus could discuss “Do only one thing but do it well” principle during hours against Systemd integration model, this would not change anything.

So, all was pretty good except one point: to know how to administer a complicated subsystem, you now had to look at the /usr/lib/systemd/system directory, grep on keywords and guess which unit files needed to be started and enabled at boot! This could become very tricky.

Some problems started with the iSCSI subsystem where a service called target.service came out(what a strange and confusing name!). This unit file didn’t even come from one of the two main iSCSI packages (targetcli and iscsi-initiator-utils) but from a dependency (python-rtslib)! To understand that you had to enable it to get your iSCSI target configuration saved took some time.

Then came some NFS interface changes with RHEL 7.1. Some service configuration files were renamed, some disappeared, others were created(*). What a mess! And no explanation at all! You had to be a NFS guru and keep reading the NFS mailing list to understand what was going on.

Now, you must ask yourself several questions:

• Why the public Red Hat documentation doesn’t yet advertise the main services and targets required when administering a subsystem like NFS? Search for nfs-client.target on the Red Hat website to get your own idea.
• Is it really the Open Source spirit? 
• Besides the .service, .target, .socket, why there isn’t a .info file describing how to administer a given subsystem?

Systemd has made maintenance of Linux distributions easier, why wouldn’t it make life of administrators easier now?
 
(*)The first command to type when taking the RHCE 7 exam is now:

# cat /etc/redhat-release