Linux

Managing Services in Linux Without systemd: A Complete Guide

This guide explains in detail how to manage system services in Linux distributions that use alternative init systems instead of systemd, such as SysVinit and OpenRC.

Updated at February 16, 2026
15-30 min
Medium
FixPedia Team
Применимо к:Alpine Linux 3.18+Debian 10+ (with sysvinit)Gentoo (OpenRC)Void Linux (runit)

Introduction / Why This Is Needed

Although systemd has become the de facto standard for most Linux distributions, there are popular and stable alternatives such as SysVinit, OpenRC, and runit. This guide will help you master service management in such environments. You will learn how to start, stop, enable at boot, and create custom scripts for managing services, which is particularly relevant for Alpine Linux, Gentoo, Void Linux, and specialized Debian/Ubuntu builds without systemd.

Requirements / Preparation

  1. Access to a Linux terminal with sudo privileges (or root).
  2. Basic understanding of the command line and the /etc/ directory structure.
  3. A text editor installed (nano, vim).
  4. Knowledge of which init system your distribution uses (see Step 1).

Step 1: Identify the Current Init System

Before starting, you need to understand which init system manages processes on your system. This is a crucial step, as commands for SysVinit and OpenRC differ.

Execute the following commands:

# Method 1: Check which process has PID 1 (this is the init system)
ps -p 1 -o comm=

# Method 2: Check the type of symbolic link /sbin/init
ls -l /sbin/init

# Method 3: For OpenRC, often there is a file /etc/openrc/conf.d
# or the presence of the /etc/runlevels/ directory
ls /etc/runlevels/ 2>/dev/null && echo "Possibly OpenRC"

Expected Results:

  • init or sysvinitSysVinit is in use.
  • openrc or runitOpenRC or runit is in use, respectively.
  • systemd → You have systemd, and this guide does not apply.

Step 2: Managing Services in SysVinit

SysVinit is the classic system that uses scripts in /etc/init.d/ and management via service and chkconfig (or update-rc.d in the Debian family).

2.1. Basic Service Operations

# Start a service (example for nginx)
sudo service nginx start

# Stop a service
sudo service nginx stop

# Restart
sudo service nginx restart

# Check status (in some systems)
sudo service nginx status

# Force configuration reload (if supported)
sudo service nginx reload

2.2. Managing Autostart

In SysVinit, autostart is managed through symbolic links in runlevel directories (/etc/rc.d/rc?.d/ or /etc/rc?.d/).

For Red Hat, CentOS, Fedora (uses chkconfig):

# Add service to autostart for runlevels 2,3,4,5
sudo chkconfig nginx on

# Remove from autostart
sudo chkconfig nginx off

# View which runlevels the service is enabled for
sudo chkconfig --list nginx

For Debian, Ubuntu (uses update-rc.d):

# Add to autostart (default for runlevels 2,3,4,5)
sudo update-rc.d nginx defaults

# Remove from autostart
sudo update-rc.d -f nginx remove

# Explicitly specify runlevels (e.g., 2,3,4,5)
sudo update-rc.d nginx start 20 2 3 4 5 . stop 80 0 1 6 .

Step 3: Managing Services in OpenRC

OpenRC is a runlevel-dependent system popular in Alpine Linux and Gentoo. The main commands are rc-service and rc-update.

3.1. Basic Service Operations

# Start a service
sudo rc-service nginx start

# Stop
sudo rc-service nginx stop

# Restart
sudo rc-service nginx restart

# Check status
sudo rc-service nginx status

# Get a list of all services and their status
rc-status --all

3.2. Managing Autostart (Runlevel)

In OpenRC, services are added to a runlevel (boot level), such as default (analogous to multi-user.target) or nonetwork.

# Add service to the 'default' runlevel (autostart on normal boot)
sudo rc-update add nginx default

# Remove service from runlevel
sudo rc-update del nginx default

# View which services are added to the 'default' runlevel
rc-update show default

# List all available runlevels
rc-update -v

Step 4: Creating and Configuring a Custom Init Script

Sometimes you need to create a script for your own application. An example for SysVinit (the logic for OpenRC is very similar, but there are nuances in the script header).

  1. Create the script file in /etc/init.d/:
    sudo nano /etc/init.d/myapp
    
  2. Add the following content (adapt for your application):
    #!/sbin/runscript
    # Copyright (c) 2026 FixPedia Team
    # Service name
    description="My custom service"
    # Start command (path to binary or script)
    command="/usr/local/bin/myapp"
    # Command options
    command_args="--config /etc/myapp/config.conf"
    # User to run as (optional)
    # user="myuser"
    # PID file (if the application writes its own PID)
    # pidfile="/run/myapp.pid"
    
    depend() {
        # Specify dependencies, e.g., on network or a directory
        # need net
        # use dns
    }
    
    start() {
        ebegin "Starting MyApp"
            start-stop-daemon --start --exec $command -- $command_args
        eend $?
    }
    
    stop() {
        ebegin "Stopping MyApp"
            start-stop-daemon --stop --exec $command --retry=TERM/30/KILL/5
        eend $?
    }
    

    For OpenRC, the script also starts with #!/sbin/runscript, but the start()/stop() functions are written without start-stop-daemon, using a direct call to $command. See man openrc-run for details.
  3. Make the script executable:
    sudo chmod +x /etc/init.d/myapp
    
  4. For SysVinit: add it to autostart (see Step 2.2). For OpenRC: add it to a runlevel (see Step 3.2).

Step 5: Checking Status and Logs

After configuring a service, it's important to ensure it's running correctly.

# For SysVinit
sudo service myapp status
# Or check the process
ps aux | grep myapp

# For OpenRC
sudo rc-service myapp status
rc-status

# View logs (depends on syslog configuration)
sudo tail -f /var/log/syslog
# Or /var/log/messages, /var/log/daemon.log

# If systemd-journald is used as a logger (possible in hybrid systems)
sudo journalctl -u myapp -f

Common Issues

  • "Permission denied" error when running the script: Ensure the script in /etc/init.d/ is executable (chmod +x). Check permissions on the service's executable file.
  • Service not adding to autostart: In SysVinit, check for symbolic links in /etc/rc?.d/. In OpenRC, ensure the service is added to the correct runlevel (rc-update show).
  • Service starts but immediately crashes: Check the logs (see Step 5). Common causes: incorrect path to the binary, missing configuration file, insufficient permissions (try user= in an OpenRC script or start-stop-daemon --chuid).
  • Service dependencies: If your service requires a network or database, be sure to specify dependencies in the script (depend() in OpenRC or # Required-Start: comments in SysVinit). This prevents race conditions during startup.
  • Service does not respond to stop: The stop script might not handle signals correctly. Use start-stop-daemon --stop --retry=TERM/30/KILL/5 for a graceful shutdown.

F.A.Q.

What is the main difference between SysVinit and systemd?
Which Linux distribution does not use systemd by default?
Is it safe to manually manage critical services via scripts?
Can I use `systemctl` in a distribution without systemd?

Hints

Identify the current init system
Managing services in SysVinit
Managing services in OpenRC
Creating and configuring your own init script
Checking status and logs
FixPedia

Free encyclopedia for fixing errors. Step-by-step guides for Windows, Linux, macOS and more.

© 2026 FixPedia. All materials are available for free.

Made with for the community