Are legacy SysV init scripts still supported in RHEL 7 and higher?

Solution Verified - Updated -

Environment

  • Red Hat Enterprise Linux 7
  • Red Hat Enterprise Linux 8
  • Red Hat Enterprise Linux 9

Issue

  • Will my application or service which still uses legacy SysV init style script still work in RHEL 9?
  • How can I ensure my init scripts continue to work in RHEL 9?

Resolution

While RHEL 7 and higher use systemd moving forward, initscripts packages are still provided for the sole purpose of supporting legacy Red Hat provided scripts only. It is NOT intended to be used for 3rd party init scripts, and doing so can cause problems on the system such as boot failures or service failures. Additionally, 3rd party scripts are not covered by Red Hat's scope of support. The functionality therefore exists, but using it with 3rd party legacy init scripts is not supported.

We cannot guarantee that any 3rd party legacy init scripts will function as intended due to the nature of how systemd works with sysvinit, and cannot guarantee those scripts will work in the future. Ultimately it is recommended to contact the vendor that provides these scripts and ask them to provide proper systemd service units, or work with them for support if they cannot due so.

It is highly recommended that all init scripts be converted to into systemd services files to ensure continued compatibility with future releases of RHEL. The following article describes in detail on how to convert a basic example of a init script/service into a systemd service file: How to convert init scripts to systemd units files 

# dnf install initscripts
  • Once an init script is installed on a RHEL 9 system or if any changes are made to it, you will need to refresh systemd in order for the changes to take effect withing systemd.
# systemctl daemon-reload
  • You can now run the init script as if it were a systemdservice by referencing it by name.
# systemctl status <init_script_name>

Please see the Root Cause section for a detailed explanation about the possible complications involved in using init scripts on a system that is running systemd

Root Cause

Starting with RHEL 7, services are managed by systemd, however partial backwards compatibility for legacy init script functionality for Red Hat provided packages is maintained by various tools/packages:

  • RHEL 7/8:
    initscripts
    chkconfig

  • RHEL 9:
    initscripts
    iniscripts-service
    chkconfig

As noted, these packages are provided for legacy RHEL provided scripts only. Issues may arise with continued usage of init scripts within an environment that is using systemd, including but not limited to boot failures and/or service failures.

Potential Issues with continued usage of init scripts within a systemd environment:

Issue 1: Startup Ordering
The first problem with init scripts is determining exactly "where" in the boot process init takes place.

All systemd service units running within userspace need a WantedBy= target defined. If we look at the systemd boot chart ( see below diagram ) we can see sysinit takes place very early in the boot process, this occurs before many of the other required targets for instance say multi-user.target (init 3) or the GUI target desktop.target (init 5) are made available:

Systemd Boot Order by Target Chart
Systemd Boot Order Chart - Source: freedesktop.org

In the past, all services were loaded in alphanumerical order within init via an init script, so you could control the order of how these init scripts loaded. Now however, since the init scripts for most core services have been moved outside of init and converted to proper systemd services/sockets/targets/timers, their load order is instead controlled by systemd which is now based on multiple conditional dependencies.

This means that there is no way for init scripts to be reliably controlled if they are loaded before or after the converted systemd services/sockets/targets/timers.

Example:

If you had a core init script that manually started a socket, and another init script that ran an application which depended upon that socket, you could configure both init scripts to start in a very specific order by naming the init scripts files with a simple alphanumeric sort order in mind:

Directory: /etc/rc.d/init.d/
Files:
01-some-socket-service-script
02-some-application-service-script

Now lets say that same old init script 01-some-socket-service-script that started a socket was now converted to a systemd service unit and assigned to multi-user.target.

File: /usr/lib/systemd/system/some.socket
Contents:
[Install]
WantedBy=multi-user.target

Now you can see the problem:

Old Boot Order: New Boot Order:
Load Kernel Load Kernel
sysinit.target sysinit.target
└─ 01-some-socket-service-script (starts some.socket) └─ 02-some-application-service-script (requires some.socket)
└─ 02-some-application-service-script (requires some.socket)
basic.target basic.target
multi-user.target multi-user.target
└─ some.socket (starts some.socket)

Now that 01-some-socket-service-script has been converted to run in systemd as some.socket it now starts in multi-user.target which starts -after- sysinit.target, causing some.socket to load out of order.

Since 02-some-application-service-script requires some.socket and it is not loaded yet due to sysinit.target starting before multi-user.target, 02-some-application-service-script will therefore fail.

Issue 2: Boot Complications
The second problem with using init scripts in a systemd based system is that it presents a point of failure during the boot-up process. This can potentially cause startup failures for anything that relies upon a service during boot and may also potentially cause the system itself to fail to boot.

As mentioned above in Issue 1: Startup Ordering during the init phase, scripts in /etc/rc.d/init.d/ load in alphanumerical order. Additionally, there may be still SOME legacy scripts required by the system that are loaded within this folder. One such example is the network script (RHEL 7).

The issue here is that if an init script fails to load, it will prevent any of the remaining scripts listed after it to not be loaded and the system may halt at this point in the boot process.

Example:

The following scripts loading during boot via init process

01-script      <--Runs properly during boot
02-script      <--Fails to load during boot
03-script      <--Requires 02-script and provides service for `network` script
S10network     <--System `network` service script (RHEL 7)

In this example, the 02-script fails to load, it can cause 03-script to fail to load. Since the 03-script is required by the system (for example our above mentioned network script), it may cause the system to not boot at all or additional systemd services to fail further into the boot process.

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.

Comments