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.
Init · Lesson 2
System V Service
Learn how to inspect and operate legacy SysV service scripts through the active system's supported wrapper.
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.
What does the service command commonly wrap?
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.
Which command requests that SysV 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
Why should reload not be assumed equivalent to restart?
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.
Does service SERVICE start necessarily enable the service at future boots?
Lesson complete
You finished System V Service
You can now operate a legacy service without confusing runtime control and boot policy.
Discover the actual script and supported actions.
Use the service name before the action in wrapper syntax.
Validate and verify reload or restart behavior.
Manage future runlevel enablement through distribution tooling.
Keep your learning progress
Create a free account to save this lesson and continue learning on any device.
Create a free account