systemctl-service-log-level

Show the current log level of a service

$ systemctl service-log-level [service_name]

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

Since systemctl-service-log-level is a conceptual task rather than a single command, its "synopsis" involves a combination of actions:

To modify a service's log level:
1. Edit application configuration:
(e.g., editing /etc/APP/app.conf to modify internal log settings.)

2. Or, edit the systemd unit file:
sudo systemctl edit --full SERVICE_UNIT
(Modify the ExecStart= line to pass log level arguments, such as ExecStart=/usr/bin/app --loglevel debug)

3. Apply unit file changes:
sudo systemctl daemon-reload

4. Restart the service:
sudo systemctl restart SERVICE_UNIT

To view a service's logs with a specific priority:
journalctl -u SERVICE_UNIT [-p PRIORITY]

SERVICE_UNIT
    The name of the systemd service unit (e.g., apache2.service, mywebapp.service) whose log level or logs are being managed.

daemon-reload
    A systemctl subcommand used to reload the systemd manager configuration. This is necessary after modifying service unit files to make systemd aware of the changes.

restart
    A systemctl subcommand used to stop and then start a specified service. Essential for applying configuration changes that affect the service's runtime behavior, including log levels.

-u, --unit
    An option for journalctl to display logs only from the specified systemd unit (service, slice, scope, etc.).

-p, --priority
    An option for journalctl to filter log messages by priority level (e.g., emerg, alert, crit, err, warning, notice, info, debug). It shows messages at or above the specified priority.

edit --full
    A systemctl subcommand used to open the full unit file for editing. It's recommended over direct file editing as it handles overrides correctly and reloads the daemon.

systemctl-service-log-level is not a standalone Linux command but rather a conceptual operation referring to the process of managing logging verbosity for services running under systemd. In a systemd environment, individual applications (wrapped as systemd services) often control their own internal log levels through their specific configuration files or command-line arguments.

The systemctl command itself is primarily used for controlling the state of these services (starting, stopping, restarting, enabling, disabling). When changes to a service's log level are desired, this typically involves modifying the application's configuration file or adjusting the ExecStart directive within the service's .service unit file (e.g., adding a --debug or --verbose flag to the application's startup command). After such modifications, systemctl is then used to daemon-reload and restart the affected service to apply the changes.

For viewing logs, the journalctl command, which interacts with systemd's unified logging system (journald), is used. It allows filtering logs by service unit, time, and even priority, giving insight into the actual log output at various verbosity levels. Therefore, managing a service's log level is a multi-step process often combining editing configuration files, using systemctl for service control, and journalctl for log inspection.

systemctl-service-log-level is not an actual command; it describes a task. Log levels are typically an internal setting of the application itself, not a direct property managed by systemd. Changing log levels usually requires modifying configuration files (either application-specific or the systemd unit file's ExecStart directive) and then restarting the service. Permissions are critical; sudo is often required for modifying systemd unit files and restarting services. Misconfiguring a service unit can prevent the service from starting.

Log levels (e.g., DEBUG, INFO, WARNING, ERROR, CRITICAL) are a common concept in software development, indicating the severity or verbosity of a log message. Setting a higher log level (e.g., ERROR) typically reduces log output, showing only critical events, whereas a lower level (e.g., DEBUG) produces very detailed output, useful for troubleshooting.

Many applications offer their own configuration files (e.g., /etc/apache2/apache2.conf for Apache, php.ini for PHP) where log levels can be directly adjusted. This is often the primary and most flexible way to manage application logging verbosity.

Instead of directly editing a package's unit file like /lib/systemd/system/service.service, it's generally recommended to create an override. This can be done with sudo systemctl edit SERVICE_UNIT. This creates an override file (e.g., /etc/systemd/system/service.service.d/override.conf) where you can add or modify specific directives, such as the ExecStart line, without altering the original file provided by the system package. This approach ensures your changes persist across package updates.

The introduction of systemd as the primary init system in many Linux distributions brought a unified approach to service management and logging. Before systemd, services often had disparate logging mechanisms (e.g., writing to /var/log/messages, /var/log/syslog, or custom application logs). Systemd's journald daemon standardized log collection, offering a centralized binary log that journalctl can query efficiently. While journald provides filtering capabilities based on log priority, the internal log level of an application remains its own domain. The conceptual "systemctl-service-log-level" task evolved as users sought ways to control the verbosity of application output within this new, unified logging framework, largely relying on application-specific settings exposed through systemd unit files.

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