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.
- 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
- 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.
Mohd Shakir Zakaria is a cloud architect with deep roots in software development and open-source advocacy. Certified in AWS, Red Hat, VMware, ITIL, and Linux, he specializes in designing and managing robust cloud and on-premises infrastructures.
