Query and Change systemd Logging with LogControl1

You will inspect the systemd manager's logging settings, make a temporary change when diagnosing a problem, and put the original values back afterwards. The normal interface is systemctl; busctl exposes the same D-Bus properties directly. Allow about ten minutes. You need a shell, a systemd host, and elevated privileges for changes to the manager's settings.

This guide describes the systemd 255 interface installed here from package version 255.4-1ubuntu8.17. Logging changes affect the manager process and can increase or redirect its output, so record the current values before writing anything.

1. Check the available commands

First confirm the installed versions and that the systemctl verbs exist. These checks are read-only and do not need sudo:

$ 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 called org.freedesktop.LogControl1. Its fixed object path is /org/freedesktop/LogControl1. Do not confuse that path with the service manager's usual /org/freedesktop/systemd1 path: the path is fixed, while the bus name identifies the daemon that implements it.

2. Record the current manager settings

Use the short systemctl commands to query the manager. The output is the value only, which makes it easy to save for a later undo:

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

The first two commands are the useful checkpoints. The installed manager may report journal-or-kmsg, a systemd target name used by the service manager. The LogControl1 specification also defines the general targets console, kmsg, journal, and syslog. The level values run from least to most verbose: emerg, alert, crit, err, warning, notice, info, and debug.

Keep the exact two values in a note before continuing. A common error is to remember the level but not the target, then restore only half of the change.

3. Raise the level for a short diagnostic window

Only do this when you need more detail from the manager. Increasing verbosity can add noise and write more journal data. The following command requires elevated privileges and changes live state:

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

The setting applies to the running manager. It is not a replacement for configuring a service's own logger, and it does not rewrite a unit file or permanently edit the journal configuration. If you only need to inspect existing messages, stop at the query step instead.

Checkpoint: reproduce the fault or collect the required diagnostic output now. Avoid leaving debug enabled indefinitely.

4. Change the log target only when there is a reason

A target controls where the daemon sends log messages. For example, this asks the manager to use the journal directly:

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

Use the target that matches your diagnostic plan. journal sends messages to systemd-journald, console uses the console or standard output, kmsg uses the kernel ring buffer, and syslog uses the syslog(3) interface. A target change can make messages appear in a different place and can disrupt an established logging path, so do not change it merely because a query returned an unfamiliar value.

If the command fails with an access error, rerun it with sudo. If it rejects a target, use only a value accepted by the installed systemctl and do not substitute a spelling from another systemd release.

5. Verify messages with journalctl

LogControl1 exposes the settings; journalctl lets you inspect messages after the change. Filter by priority and identifier when those fields are present:

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

The first command asks for the current boot and the full syslog priority range. The second filters on the syslog identifier reported by the interface on this host. The exact message set depends on the boot and activity, so an empty result does not prove that the setting failed. For transport-specific checks, journalctl can also filter _TRANSPORT=journal, _TRANSPORT=syslog, or _TRANSPORT=kernel.

Do not treat a larger journal as evidence that every daemon became more verbose. LogControl1 changes the implementing program's threshold; individual services may have their own logging controls.

6. Use busctl when you need the D-Bus properties

Use busctl to inspect the interface directly. 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 means that the D-Bus value is a string. The identifier is read-only. The other two properties are writable by sufficiently privileged users, but prefer systemctl for routine administration because it makes the intended manager operation clearer.

For a controlled property write, the D-Bus type must also be supplied:

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

Do not use both interfaces in a script unless you have a reason. Mixing them makes it easier to lose track of which process owns the setting and which value must be restored.

7. Restore the recorded values

Restoration is the undo step. Replace the placeholders with the exact values you recorded in step 2. These commands require elevated privileges if the values differ from the current settings:

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

For example, if the original output was info and journal-or-kmsg, use those exact values. Do not blindly run systemctl log-target journal as a restore command: that would be a new choice, not a return to the previous state.

Common failure modes

• Permission denied: query without elevation, but prefix a write with sudo.
• Unknown object or property: check the bus name, fixed object path, interface name, and property spelling separately. They are case-sensitive.
• No useful new messages: confirm the level with systemctl log-level, then check the manager's journal entries and the relevant boot.
• Unexpected target: keep the installed systemd version in mind. Values reported by the manager can include a systemd-specific combined target such as journal-or-kmsg.