Which commands would you use to examine boot logs and identify boot failures, and which command helps check a failed service?

• A. Journalctl -b; Systemctl status servicename
• B. Dmesg | less; Systemctl status
• C. Journalctl; Systemctl show
• D. Systemctl status; Journalctl -b

Answer: (A)

Diagnosing boot problems relies on viewing the systemd journal for the current boot and then quickly checking the status of any failing service. Journalctl -b shows all logs from this boot, including kernel messages and unit startup messages, so you can spot where the boot process ran into trouble. If a service fails to start, you’ll often see the failure reflected in the unit startup messages here. You can still use -b -1 or similar if you need to compare a prior boot.

Once you identify a failing service, systemctl status is the quickest way to confirm its state and read the reason for the failure. It tells you whether the unit is loaded, active, or failed, shows the failure reason and timing, and includes a short snippet from the relevant logs. For deeper investigation of that service’s logs, you can pair it with journalctl -u to pull logs specific to that unit.

Dmesg | less is less targeted for boot troubleshooting since it focuses on kernel messages and isn’t scoped to the current boot or specific services, and systemctl status without a unit name isn’t useful for diagnosing a particular service. Journalctl on its own shows logs, but without filtering it’s harder to quickly pinpoint boot failures, and systemctl show is more verbose and unit-specific without immediately indicating the boot-time sequence.