How to troubleshoot a Linux service outage

A Linux service outage needs a short triage path before restarts or configuration edits change the evidence. The first useful signal is the systemd unit state, because it shows whether the daemon failed to start, exited after launch, timed out, or is still running while the application remains unreachable.

systemctl reports the service state that systemd is tracking, while journalctl shows the start attempt, exit status, and daemon messages around the incident. For network-facing services, ss confirms which process owns the expected port, which separates process failures from firewall, routing, and proxy problems.

Collect the state and journal lines before applying a fix so later restarts do not replace the original failure with a new symptom. The commands use apache2.service failing because another web server owns port 80 as a concrete outage signal; replace the unit name and port with the affected service.

Steps to troubleshoot a Linux service outage with systemd:

Check the affected unit state.

$ sudo systemctl status --no-pager --full apache2.service
× apache2.service - The Apache HTTP Server
     Loaded: loaded (/usr/lib/systemd/system/apache2.service; enabled; preset: enabled)
     Active: failed (Result: exit-code) since Sat 2026-06-13 20:46:10 UTC; 11s ago
       Docs: https://httpd.apache.org/docs/2.4/
    Process: 111 ExecStart=/usr/sbin/apachectl start (code=exited, status=1/FAILURE)
   Main PID: 111 (code=exited, status=1/FAILURE)
     Status: "Reading configuration..."
##### snipped #####
Jun 13 20:46:10 host.example.net apachectl[111]: (98)Address already in use: AH00072: make_sock: could not bind to address 0.0.0.0:80
Jun 13 20:46:10 host.example.net apachectl[111]: no listening sockets available, shutting down
Jun 13 20:46:10 host.example.net systemd[1]: apache2.service: Failed with result 'exit-code'.
Jun 13 20:46:10 host.example.net systemd[1]: Failed to start apache2.service - The Apache HTTP Server.

Use the exact .service unit from the alert or application handoff. If the unit is unknown, list failed services with systemctl --failed --type=service.
Related: How to check Linux service status

Review journal entries for the same boot.

$ sudo journalctl --unit=apache2.service --boot --no-pager --lines=20
Jun 13 20:46:06 host.example.net systemd[1]: Starting apache2.service - The Apache HTTP Server...
Jun 13 20:46:06 host.example.net apachectl[58]: (98)Address already in use: AH00072: make_sock: could not bind to address 0.0.0.0:80
Jun 13 20:46:06 host.example.net apachectl[58]: no listening sockets available, shutting down
Jun 13 20:46:06 host.example.net systemd[1]: apache2.service: Main process exited, code=exited, status=1/FAILURE
Jun 13 20:46:06 host.example.net systemd[1]: apache2.service: Failed with result 'exit-code'.
Jun 13 20:46:06 host.example.net systemd[1]: Failed to start apache2.service - The Apache HTTP Server.
Jun 13 20:46:10 host.example.net systemd[1]: Starting apache2.service - The Apache HTTP Server...
Jun 13 20:46:10 host.example.net apachectl[111]: (98)Address already in use: AH00072: make_sock: could not bind to address 0.0.0.0:80
Jun 13 20:46:10 host.example.net apachectl[111]: no listening sockets available, shutting down
Jun 13 20:46:10 host.example.net systemd[1]: apache2.service: Failed with result 'exit-code'.

Start with the earliest failure in the window; repeated restarts often duplicate the same message.
Related: How to view Linux service logs with journalctl

Print stable state fields for the incident record.

$ systemctl show apache2.service --property=LoadState,ActiveState,SubState,Result,ExecMainStatus,NRestarts
LoadState=loaded
ActiveState=failed
SubState=failed
Result=exit-code
NRestarts=0
ExecMainStatus=1

Result=exit-code and ExecMainStatus=1 identify a failed start. NRestarts shows automatic restarts tracked for the unit.

Check the expected port when the log shows a bind failure.

$ sudo ss --listening --tcp --numeric --processes '( sport = :80 )'
State  Recv-Q Send-Q Local Address:Port Peer Address:PortProcess
LISTEN 0      511          0.0.0.0:80        0.0.0.0:*    users:(("nginx",pid=1234,fd=5))
LISTEN 0      511             [::]:80           [::]:*    users:(("nginx",pid=1234,fd=6))

A listener owned by a different daemon explains the bind failure. For non-network services, inspect the failed path, dependency, socket, queue, or credential named in the journal instead.
Related: How to check if a Linux service is listening on a port

Stop the service that should not own the port.
```
$ sudo systemctl stop nginx.service
```
Choose the service that should give up the port before stopping anything; stopping the wrong service can extend the outage.

Related: How to manage a Linux service with systemctl
Clear the failed marker after the cause is corrected.
```
$ sudo systemctl reset-failed apache2.service
```
reset-failed also clears the per-unit start-rate counter, which matters when start-limit-hit prevented another start attempt.
Start the affected service.
```
$ sudo systemctl start apache2.service
```
Related: How to manage a Linux service with systemctl

Confirm the service state after restart.

$ systemctl show apache2.service --property=ActiveState,SubState,Result,ExecMainStatus,NRestarts
ActiveState=active
SubState=running
Result=success
NRestarts=0
ExecMainStatus=0

Confirm the expected port now belongs to the recovered service.

$ sudo ss --listening --tcp --numeric --processes '( sport = :80 )'
State  Recv-Q Send-Q Local Address:Port Peer Address:PortProcess
LISTEN 0      511          0.0.0.0:80        0.0.0.0:*    users:(("apache2",pid=1234,fd=3))

Test a local connection to the service port.
```
$ nc -vz 127.0.0.1 80
Connection to 127.0.0.1 80 port [tcp/*] succeeded!
```
A successful TCP connection proves the socket accepts a handshake. For HTTP, SSH, databases, or queues, follow with a protocol-level request from the application path.