Systemd Parallel Execution Fallout

The Linux boot manager, systemd, speeds up the boot time of a computer running Linux by executing startup tasks in parallel. This is great, for the most part, but does introduce some potential issues depending on how your system is configured. For a stand-alone workstation or server, chances are you may never run into problems. Introduce some network-based services, however, and the odds start to turn the other way.

Allow me to introduce the following configuration, and discuss how systemd needed to be tuned to provide an operational environment:

  1. Workstations and servers use automount and NFS to mount file systems of shared data and user home directories.
  2. To manage user logins openLDAP (or AD) is used and the sssd daemon manages this configuration.
  3. The system clock is synced using the chrony daemon.
  4. Users rely on cron to startup their services at boot time using @restart in their crontab files, which point to startup scripts in their NFS-mounted home directories.

Now, let’s consider how the system boots using vanilla systemd – with no pre-configured dependencies on the network being active, automount, nfs, sssd, cron, and chrony all start in parallel. While some of these daemons are tolerant of missing network activity, many are not.

Startup scripts in the user’s cron files may not execute, because the system has no ownership data for the cron file, as sssd has not started or is not able to query AD/LDAP. In addition, the NFS-mounted home directory for the user is not present, so the cron entry points to an invalid location. If your NFS mounts are not done using automount, they may fail entirely if not made using the background option.

You get the idea… We must configure network-aware services correctly to ensure we have dependable and consistent services start at system boot. To do this, we modify files in the /etc/systemd/service directory. If you are using configuration management (puppet, etc..) be sure to do this using that facility. Provided below are the configuration files used to stabilize the environment described above.