System V Service

SysV services are commonly represented by executable scripts under /etc/init.d/. A script accepts actions such as start, stop, restart, or status according to its implementation and distribution conventions. The service command provides a wrapper that runs a named script in a more controlled environment.

Discovering Services and Actions

List script names first:

$ ls -1 /etc/init.d/

Some implementations provide:

$ service --status-all

Its bracket markers and exit statuses are wrapper-specific, and a script can report unknown status. For one service, inspect the script's usage output or documentation rather than assuming every action exists.

CheckWhat does the service command commonly wrap?

A disk partition editor running on every service file. A kernel system call added dynamically by the script. A named init script and one of its supported actions.

Starting and Stopping

On an actual SysV-managed host, these forms are common:

$ sudo service SERVICE_NAME start
$ sudo service SERVICE_NAME stop

Replace the placeholder only after identifying the service, its dependents, current state, and operational impact. Stopping networking, remote access, storage, or authentication from a remote session can lock you out or corrupt active work.

The direct form /etc/init.d/SERVICE_NAME ACTION can exist, but on a host whose active manager provides compatibility, use the manager-facing command so it can track state and dependencies.

CheckWhich command requests that SysV service peanut stop?

sudo service stop peanut sudo stop --partition peanut sudo service peanut stop

Reload, Restart, and Status

restart normally stops then starts a service, causing interruption. reload can ask a service to reread configuration without a full restart, but only when the script and daemon support it. Some scripts offer force-reload with distribution-defined fallback behavior.

Validate configuration before any reload or restart, preserve a second administrative connection for remote-access changes, and verify the service afterward through its actual endpoint and logs—not only a “running” status.

$ sudo service SERVICE_NAME status
$ sudo service SERVICE_NAME reload

CheckWhy should reload not be assumed equivalent to restart?

Reload always shuts down the entire operating system. Restart only prints configuration and never changes process state. Reload is service-specific and can reread configuration without stopping the process.

Runtime Control versus Boot Enablement

Starting a service now does not necessarily enable it for future runlevels. Boot enablement is represented by runlevel links and managed with distribution-specific tools such as update-rc.d, chkconfig, or service-manager compatibility generators.

Do not create S and K links manually until you understand the distribution's dependency metadata and management tool; manual links can be overwritten or ordered incorrectly.

CheckDoes service SERVICE start necessarily enable the service at future boots?

Yes; every start action creates all runlevel links automatically. No; runtime state and runlevel enablement are separate. Yes; a running PID is stored permanently in the boot sector.

Summary

You can now operate a legacy service without confusing runtime control and boot policy.

1. Discover the actual script and supported actions.
2. Use the service name before the action in wrapper syntax.
3. Validate and verify reload or restart behavior.
4. Manage future runlevel enablement through distribution tooling.