How to Start a SysV Init Script After Network Starts

Red Hat

- 2 minutes read - 385 words

If you are porting a legacy platform from RHEL 5 to RHEL 7, you may find that chkconfig’d SysVinit services start before the network or NFS mounts they depend on. The fix is simpler than writing a new systemd unit: systemd already reads the LSB headers in your existing init script, so you just need to declare the dependency correctly.

Environment

  • Red Hat Enterprise Linux 7
  • SysVinit service script
  • systemd

Issue

  • systemd includes compatibility for SysVinit service scripts in /etc/rc.d, but how do you configure dependencies so a third-party initscript does not start until after a native systemd unit (like networking) is ready?
  • Legacy chkconfig’d services are starting before network and NFS, which are hard dependencies.
  • The init script cannot be converted to a native systemd unit file.

Resolution

Add the Required-Start: $network directive to the LSB header of your SysVinit script. Here is the header from the rhnsd service script as a reference:

$ awk '/### BEGIN INIT INFO/,/### END INIT INFO/' /etc/init.d/rhnsd
### BEGIN INIT INFO
# Provides: rhnsd
# Required-Start: $local_fs $network $remote_fs $named $time
# Required-Stop: $local_fs $network $remote_fs $named
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Starts the Spacewalk Daemon
# Description: This is a daemon which handles the task of connecting
#               periodically to the Spacewalk servers to
#               check for updates, notifications and perform system
#               monitoring tasks according to the service level that
#               this server is subscribed for.
### END INIT INFO
Important

The $network token in the LSB header is the key. systemd translates it into After=network-online.target automatically, so you do not need to write a separate unit file.

Root Cause

systemd honors the LSB headers in init scripts. When it encounters $network in the Required-Start line, it maps that to the network-online.target ordering dependency. Without that directive, the service has no ordering guarantee relative to the network stack.

Diagnostic Steps

To confirm which services are starting out of order, generate a startup plot:

systemd-analyze plot > analyzestartup.svg

Open analyzestartup.svg in Firefox or any image viewer to inspect the startup sequence visually.

References