A service looks healthy now, but it reportedly failed right after a reboot. Reading every log entry can mix an earlier incident with the current one. Filter by service name and boot separately: journalctl -u selects a unit's messages, while -b narrows them to a boot.
journalctl -u selects a service's records
-u selects messages for demo-web, and -b limits the result to the current boot. Assuming earlier boot logs have been retained, -u alone can include them; together, the options show only the current boot's matching records.
demo-web.service is an illustrative unit name. On a real system, first confirm the unit name shown by systemctl status.
sudo systemctl status demo-web.service
sudo journalctl -u demo-web.serviceThe first command provides current status and clues from related messages. The second shows records for that service. Without filters, journalctl may mix in messages from other accessible services. With only -u, retained records from previous boots may appear too. Whether those records exist depends on the system's journal retention settings.
Add -b to limit results to this boot
Combine the filters when investigating a problem immediately after a reboot.
sudo journalctl -b -u demo-web.service-b selects the current boot and -u selects the specified service. Together, they narrow the result to messages related to that service during this boot. The systemd journalctl documentation describes the boot filter.
An empty result does not prove the service is healthy. The unit name may be wrong, you may lack permission to read the relevant records, or logs may not have been retained. Check the name, permissions, and boot range in that order. Read the sequence around the failure time rather than drawing a conclusion from one line.
What should you compare after finding an error?
If the status says failed and the logs show that an executable could not be found, inspect the service configuration and file path. If a connection fails before the network is ready, inspect startup order and dependencies. These are possible investigative directions, not reproductions of a particular server incident.
Repeatedly restarting the service can create more failure events and make the original one harder to identify. Record the time and log range first, change one setting, then retry. Logs can include user input or sensitive error details, so redact them before sharing externally.
Key takeaways: combine the service and boot filters
journalctl -u UNIT shows that unit's records; journalctl -b -u UNIT shows its records from the current boot. If the result is empty, check the name, permissions, and retention instead of assuming the service is healthy.
