systemctl-log-level

Show the current log level of the systemd manager

$ systemctl log-level

$ systemctl log-level [emerg|alert|crit|err|warning|notice|info|debug]

As 'systemctl-log-level' is not a single command, its synopsis represents the primary method for filtering existing logs by level:
journalctl -p LEVEL

LEVEL
    Specifies the minimum priority level for messages to display. Messages with a lower priority number (higher severity) than the specified level will also be shown. Possible values, from most severe to least:
emerg (0), alert (1), crit (2), err (3), warning (4), notice (5), info (6), debug (7). You can use either the name or the numerical value.

The term 'systemctl-log-level' does not refer to a single, standalone Linux command. Instead, it encompasses the methods and configurations within the systemd ecosystem for managing the verbosity of system logs and filtering them by priority. Systemd, through its journald component, collects and stores log data from the kernel, services, and applications.

While there isn't a direct `systemctl log-level` subcommand, users can utilize various approaches to interact with log levels:

1. View Logs by Level: Use `journalctl -p ` to filter existing logs based on their severity (e.g., `emerg`, `alert`, `crit`, `err`, `warning`, `notice`, `info`, `debug`).
2. Configure Global Systemd Log Level: Modify the `LogLevel` parameter in `/etc/systemd/system.conf` to set the default logging level for the systemd manager itself.
3. Set Service-Specific Log Level: For individual services, log levels are typically managed within the service's own configuration files, environment variables, or sometimes through `systemd.unit` file options like `LogLevel` (though less common for direct application logging).

Understanding 'systemctl-log-level' means understanding these distinct approaches to log management within a systemd environment.

The term 'systemctl-log-level' is not a standard Linux command. Any usage of it likely refers to a custom script or a general concept of managing log verbosity within systemd. Changing global systemd log levels (via `/etc/systemd/system.conf`) requires `systemctl daemon-reexec` and affects all systemd processes, potentially generating a large volume of logs for debug levels or hiding critical information for higher levels. Similarly, modifying service log levels directly impacts the verbosity of that specific service.

To change the global logging verbosity for the systemd manager itself, edit the `LogLevel` parameter in the `/etc/systemd/system.conf` file. After saving changes, run `systemctl daemon-reexec` to apply the new setting. Be cautious with `debug` levels on production systems as they can generate excessive logs.

For most applications, their logging level is configured within their own specific configuration files (e.g., `/etc/apache2/apache2.conf`), environment variables, or command-line arguments. Systemd unit files (e.g., `/etc/systemd/system/my-service.service`) can sometimes include `LogLevel=` in the `[Service]` section for internal systemd messages related to the unit, or `Environment=` directives to pass logging settings to the application.

The concept of log levels has been fundamental to Unix-like systems for decades (e.g., syslog priorities). Systemd, introduced in 2010, brought its own logging system, journald, which integrates these concepts. Journald standardizes log collection, storage, and querying, replacing older fragmented logging solutions. While log levels themselves are an old concept, their structured management and querying via `journalctl` represent a significant evolution in system logging.

journalctl(1), systemctl(1), systemd(1), systemd.conf(5), systemd.unit(5)