Turn Up systemd Logging with LogControl1

A service is misbehaving and the journal has nothing useful in it, so you need the manager itself to talk more, briefly, on purpose. This guide shows you how to read and change that logging level with systemctl or raw D-Bus, then put it back. Allow about ten minutes.

You need a shell, a systemd host, and elevated privileges for the write steps; the queries need none. This describes the systemd 255 interface, package version 255.4-1ubuntu8.17.

1. Check the commands exist

Confirm the installed version and that the verbs are there. Both checks are read-only:

$ systemctl --version
systemd 255 (255.4-1ubuntu8.17)
$ systemctl --help | grep -E 'log-level|log-target'
  log-level [LEVEL]                   Get/set logging threshold for manager
  log-target [TARGET]                 Get/set logging target for manager

The D-Bus interface is org.freedesktop.LogControl1, at the fixed object path /org/freedesktop/LogControl1. Do not confuse that with the service manager's usual /org/freedesktop/systemd1 path: the path is fixed, the bus name tells you which daemon implements it.

2. Write down the current settings

Query before you touch anything. The output is the value only, which is exactly what you want to paste back later:

$ systemctl log-level
info
$ systemctl log-target
journal-or-kmsg
$ systemctl show --property=LogLevel --property=LogTarget systemd

Levels, least to most verbose: emerg, alert, crit, err, warning, notice, info, debug.

Targets: console, kmsg, journal, syslog, plus the systemd-specific combined target journal-or-kmsg you will often see reported back.

Tip: write down both values, not just the level. The classic mistake is remembering the level and forgetting the target, then only half-restoring things later.

3. Raise the level for a short window

Only do this when you actually need more detail. It adds noise and writes more journal data. This changes live state and needs elevated privileges:

$ sudo systemctl log-level debug
$ systemctl log-level
debug

This applies to the running manager only. It does not touch a service's own logger, does not rewrite a unit file, and does not permanently edit journal configuration. If you just want to read existing messages, skip this step entirely.

Checkpoint: reproduce the fault or capture the diagnostic output now, then move on. Do not leave debug switched on indefinitely.

4. Change the target, but only with a reason

The target decides where log messages go. For example, sending the manager's output straight to the journal:

$ sudo systemctl log-target journal
$ systemctl log-target
journal

• journal sends messages to systemd-journald.
• console uses the console or standard output.
• kmsg uses the kernel ring buffer.
• syslog uses the syslog(3) interface.

Changing the target moves where messages appear and can break an established logging path, so do not flip it just because a query returned a value you did not expect.

If the command fails on permissions, rerun it with sudo. If it rejects a target name, use only what the installed systemctl accepts: do not borrow a spelling from a different systemd release.

5. Check the messages with journalctl

LogControl1 changes the settings; journalctl is how you see the result. Filter by priority and identifier where those fields exist:

$ sudo journalctl -b -p debug..emerg --no-pager
$ sudo journalctl -b -t systemd --no-pager

The first command covers the current boot across the full priority range. The second filters on the syslog identifier the interface reports for this host. An empty result does not prove the setting failed: it depends on the boot and what actually happened during it. For transport-specific checks, journalctl can also filter _TRANSPORT=journal, _TRANSPORT=syslog, or _TRANSPORT=kernel.

A bigger journal is not proof every daemon got chattier. LogControl1 only changes the implementing program's own threshold; other services have their own logging controls.

6. Go direct with busctl

Use busctl when you want the D-Bus properties themselves. These reads are ordinary, non-destructive queries:

$ busctl get-property org.freedesktop.systemd1 \
    /org/freedesktop/LogControl1 \
    org.freedesktop.LogControl1 LogLevel
s "info"
$ busctl get-property org.freedesktop.systemd1 \
    /org/freedesktop/LogControl1 \
    org.freedesktop.LogControl1 LogTarget
s "journal-or-kmsg"
$ busctl get-property org.freedesktop.systemd1 \
    /org/freedesktop/LogControl1 \
    org.freedesktop.LogControl1 SyslogIdentifier
s "systemd"

The leading s just means the value is a D-Bus string. The identifier is read-only; the other two properties are writable by anyone with enough privilege, but prefer systemctl for routine work because the intent is clearer. A property write needs the D-Bus type spelled out too:

$ sudo busctl set-property org.freedesktop.systemd1 \
    /org/freedesktop/LogControl1 \
    org.freedesktop.LogControl1 LogLevel s debug
$ systemctl log-level
debug

Do not mix both interfaces in the same script without a reason: it makes it easy to lose track of which value you still owe a restore.

7. Restore the recorded values

This is the undo step. Swap in the exact values from step 2, not a guess. Both commands need elevated privileges if the current values differ:

$ sudo systemctl log-level ORIGINAL_LEVEL
$ sudo systemctl log-target ORIGINAL_TARGET
$ systemctl log-level
ORIGINAL_LEVEL
$ systemctl log-target
ORIGINAL_TARGET

Example: if step 2 gave you info and journal-or-kmsg, use those exact values. Warning: do not run systemctl log-target journal as a shortcut restore. That is a new choice, not a return to the previous state, unless journal is genuinely what you recorded.

Common failure modes

• Permission denied. Query without elevation, but prefix any write with sudo.
• Unknown object or property. Check the bus name, object path, interface name and property spelling one at a time. All of it is case-sensitive.
• No useful new messages. Confirm the level with systemctl log-level, then check the manager's own journal entries for the right boot.
• Unexpected target reported back. Remember the installed systemd version: managers can report a systemd-specific combined target such as journal-or-kmsg.