A service will not start or a feature fails? Status and time-matched logs help narrow down the cause before a restart changes the evidence. This guide applies to systemd systems. example.service is a placeholder for the actual affected service.
Step by step
- Record the incident time, time zone and affected feature. Find the exact unit name in application documentation or with
systemctl list-units --type=service --all. Names can differ between distributions. - Read
systemctl status example.service --no-pager --full. Distinguish Loaded, Active and specific errors. ‘enabled’ describes startup enablement, not proof that the application currently works correctly. - Read
journalctl -u example.service -b -n 100 --no-pager. This restricts output to the current boot and the last 100 matching entries. For an older incident, that restriction may exclude the messages you need. - If needed use
journalctl -u example.service --since '2026-09-16 12:00:00' --until '2026-09-16 12:30:00' --no-pager, replacing both example times. Check the system time zone. Read messages immediately before the failure too. - For a user service,
systemctl --user status example.serviceandjournalctl --user -u example.serviceare appropriate. Use the affected user account. Missing journal entries may also mean insufficient reading permission, separate log files or expired retention.
Check the result
Record the first specific error, its time and the service state. Check the actual application feature separately: ‘active’ alone does not prove a successful login, request or data processing. Derive a targeted next test, not a series of arbitrary restarts.
Undo and limitations
These commands read information and do not change the service. Before restarting, changing configuration or using reset-failed, establish impact and a recovery path. Logs may contain confidential details; share only necessary, sanitized extracts.