Bird
Raised Fist0
Linux CLIscripting~5 mins

journalctl for systemd logs in Linux CLI - Commands & Configuration

Choose your learning style10 modes available
Introduction
Systemd manages many services on Linux and keeps logs of their activity. journalctl is a command that helps you read these logs easily to understand what is happening or troubleshoot problems.
When you want to see recent system errors to fix a problem with your computer.
When you need to check if a service started correctly after a reboot.
When you want to watch live logs as a program runs to understand its behavior.
When you want to filter logs by a specific service to focus on its messages.
When you want to check logs from a past boot to investigate an issue that happened earlier.
Commands
Shows the most recent system logs with extra details and highlights important messages. Useful for quick troubleshooting.
Terminal
journalctl -xe
Expected OutputExpected
Jun 10 14:22:01 my-computer systemd[1]: Starting Daily Cleanup... Jun 10 14:22:02 my-computer systemd[1]: Started Daily Cleanup. Jun 10 14:23:45 my-computer sshd[1234]: Accepted password for user from 192.168.1.5 port 54321 ssh2
→
-x - Show explanatory help for log messages
→
-e - Jump to the end of the journal to see latest logs
Filters logs to show only messages related to the sshd service. Helps focus on one service's logs.
Terminal
journalctl -u sshd.service
Expected OutputExpected
Jun 10 14:20:00 my-computer systemd[1]: Starting OpenSSH server daemon... Jun 10 14:20:01 my-computer sshd[1200]: Server listening on 0.0.0.0 port 22. Jun 10 14:23:45 my-computer sshd[1234]: Accepted password for user from 192.168.1.5 port 54321 ssh2
→
-u - Specify the systemd unit (service) to filter logs
Shows logs from the previous boot. Useful to investigate problems that happened before the current session.
Terminal
journalctl -b -1
Expected OutputExpected
Jun 09 08:00:00 my-computer systemd[1]: Starting Network Manager... Jun 09 08:00:01 my-computer systemd[1]: Started Network Manager. Jun 09 08:05:12 my-computer kernel: usb 1-1: new high-speed USB device number 2 using xhci_hcd
→
-b - Show logs from a specific boot
→
-1 - Select the previous boot (one before current)
Follows the journal live, showing new log entries as they happen. Like watching a live feed of system messages.
Terminal
journalctl -f
Expected OutputExpected
Jun 10 14:25:00 my-computer systemd[1]: Starting Backup Service... Jun 10 14:25:01 my-computer backup[2345]: Backup started
→
-f - Follow logs live, showing new entries as they appear
Key Concept

If you remember nothing else from this pattern, remember: journalctl lets you read and filter systemd logs easily to find and understand system events.

Common Mistakes
Running journalctl without sudo and getting permission denied errors.
Normal users often cannot read system logs without proper permissions.
Run journalctl commands with sudo to access all system logs.
Using journalctl without any filters and getting overwhelmed by too many logs.
The journal contains all system logs, which can be very large and hard to read.
Use filters like -u for services or -b for boots to narrow down the logs.
Trying to read logs from a service that is not managed by systemd.
journalctl only shows logs from systemd-managed services.
Check if the service uses systemd and use other log tools if not.
Summary
Use journalctl -xe to see recent detailed system logs for quick troubleshooting.
Filter logs by service with journalctl -u servicename to focus on specific components.
Use journalctl -b -1 to view logs from the previous boot session.
Follow live logs with journalctl -f to watch system events as they happen.

Practice

(1/5)
1. What is the primary purpose of the journalctl command in Linux?
easy
A. To edit configuration files for systemd services
B. To start and stop systemd services
C. To view system and service logs managed by systemd
D. To display disk usage statistics

Solution

  1. Step 1: Understand the role of journalctl

    The journalctl command is used to access logs collected by systemd's journal service.
  2. Step 2: Compare options with command purpose

    Editing configuration files, starting/stopping services, and displaying disk usage are handled by other commands, unrelated to viewing logs.
  3. Final Answer:

    To view system and service logs managed by systemd -> Option C
  4. Quick Check:

    journalctl = view logs [OK]
Hint: Remember: journalctl = journal + control = view logs [OK]
Common Mistakes:
  • Confusing journalctl with systemctl for service control
  • Thinking journalctl edits files
  • Assuming journalctl shows disk info
2. Which of the following is the correct syntax to show the last 10 lines of system logs using journalctl?
easy
A. journalctl -n 10
B. journalctl --last 10
C. journalctl -l 10
D. journalctl -t 10

Solution

  1. Step 1: Recall journalctl option for number of lines

    The -n option followed by a number shows that many recent log lines.
  2. Step 2: Check other options for correctness

    The other options are not valid journalctl options for limiting output lines.
  3. Final Answer:

    journalctl -n 10 -> Option A
  4. Quick Check:

    -n = number of lines [OK]
Hint: Use -n to limit lines shown quickly [OK]
Common Mistakes:
  • Using --last instead of -n
  • Confusing -l (line wrap) with line count
  • Using -t which filters by syslog identifier
3. What will be the output of the command journalctl -u sshd.service -n 3?
medium
A. Shows the last 3 log entries related to the sshd service
B. Shows all logs except those from sshd service
C. Shows the first 3 lines of the system log
D. Shows logs from all services except sshd

Solution

  1. Step 1: Understand the -u option

    The -u sshd.service option filters logs to only those from the sshd service.
  2. Step 2: Understand the -n 3 option

    The -n 3 option limits output to the last 3 log entries.
  3. Final Answer:

    Shows the last 3 log entries related to the sshd service -> Option A
  4. Quick Check:

    -u sshd + -n 3 = last 3 sshd logs [OK]
Hint: -u filters by service, -n limits lines [OK]
Common Mistakes:
  • Thinking -u excludes the service logs
  • Confusing -n with showing first lines
  • Assuming it shows all logs
4. You run journalctl -u nginx.service --since "2024-01-01" --until "2024-01-02" but get no output, even though you know nginx was active. What is the likely problem?
medium
A. The date format is incorrect; journalctl requires YYYY-MM-DD HH:MM:SS
B. The service name is wrong; it should be nginx without .service
C. The journal is empty because logging is disabled
D. The system clock is set to a different timezone causing no matching logs

Solution

  1. Step 1: Check date format validity

    The date format "YYYY-MM-DD" is valid for journalctl; it does not require HH:MM:SS.
  2. Step 2: Consider timezone impact

    If the system clock or journal timestamps use a different timezone, the specified range may not match any logs, causing no output.
  3. Step 3: Verify service name and logging

    The service name with .service is correct, and nginx is usually logged to the journal, making incorrect service name or disabled logging unlikely.
  4. Final Answer:

    The system clock is set to a different timezone causing no matching logs -> Option D
  5. Quick Check:

    Timezone mismatch = no logs in range [OK]
Hint: Check timezone if date filters show no logs [OK]
Common Mistakes:
  • Assuming date format is wrong
  • Removing .service from unit name
  • Ignoring system clock timezone
5. You want to monitor live logs from the docker.service as they happen. Which command should you use?
hard
A. journalctl -u docker.service --since now
B. journalctl -u docker.service -f
C. journalctl -u docker.service -n 0
D. journalctl -u docker.service --no-pager

Solution

  1. Step 1: Identify option for live log streaming

    The -f option in journalctl streams new log entries live, similar to tail -f.
  2. Step 2: Evaluate other options

    journalctl -u docker.service --since now shows logs since now but does not follow live updates. journalctl -u docker.service -n 0 shows zero lines, so no output. journalctl -u docker.service --no-pager disables paging but does not stream live.
  3. Final Answer:

    journalctl -u docker.service -f -> Option B
  4. Quick Check:

    -f = follow live logs [OK]
Hint: Use -f to follow logs live like tail -f [OK]
Common Mistakes:
  • Using --since now without -f for live updates
  • Using -n 0 which shows no lines
  • Confusing --no-pager with live streaming
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard