System logger


slogger2 [-C dev_console_buffer_size] [-c out_buffer_size,error_buffer_size]
         [-D slogger2_asinfo_name[:dump_file]] [-d slogger2_asinfo_name[:dump_file]]
         [-g gid1,gid2,...] [-l log_save_path] [-P pps_path] [-S] [-s size]
         [-U string] [-v[v]...]

Runs on:

QNX Neutrino


-C dev_console_buffer_size
(QNX Neutrino 7.0 or later) Specify the buffer size to use for /dev/console, which provides a general-purpose console logging node. The size is in bytes, but you can specify a (case-sensitive) suffix of k to specify a size in kilobytes. By default, this feature is enabled with a buffer size of 16 KB. To disable it, set the size to 0.
-c out_buffer_size,error_buffer_size
(QNX Neutrino 7.0 or later) Create a buffer set containing two logging buffers (out and error) with the given sizes, in bytes. You can write to these buffers by opening the following paths for writing:
Path Buffer
/dev/slog2/critical error
/dev/slog2/error error
/dev/slog2/warning out
/dev/slog2/info out
/dev/slog2/debug out

Each log line is prefixed with the process ID of the client, in square brackets.

-D slogger2_asinfo_name[:dump_file]
-d slogger2_asinfo_name[:dump_file]
(QNX Neutrino 7.0 or later) Allow slogger2 buffer sets to be backed against a known location in physical memory, for possible recovery after a warm reset.

The slogger2_asinfo_name argument is the name of the address space memory region in the system page (syspage) that's been set aside for this purpose.

If the pre-reset state of the logs is determined to be intact, it's saved in /dev/shmem/dump_file. The default value of dump_file is slog2phys.

The -d option tries to use physical memory backing only if you pass the SLOG2_ALLOC_TYPE_PHYSICAL flag to slog2_register(). The -D option tries to use physical memory backing for every buffer set.

If physical memory is depleted and can't be reclaimed from previous dead processes, then the buffer set is created as a regular shared memory object.

-g gid1,gid2,...
(QNX Neutrino 7.0 or later) Add each group in the list to every buffer set as a read-only ACL entry.
-l log_save_path
(QNX Neutrino 7.0 or later) When a client process stops or terminates, copy its associated buffer set(s) under /dev/shmem/slogger2/ to log_save_path.

This is mainly intended as a debugging feature.

The default behavior of slogger2 once a client disconnects is to postpone the immediate cleanup of resources associated with the respective buffer set(s) until a later time. The present implementation relies on a queue of disconnected clients.

-P pps_path
(QNX Neutrino 7.0 or later) Use an optional PPS interface for slogger2 that provides a command-line interface that's equivalent to the slog2_get_verbosity() and slog2_set_verbosity() APIs.

The slogger2 APIs filter which logs actually get appended into any of the logging buffers in the buffer set, based on the verbosity level of the buffer set and the severity level passed to the vslog2*() and slog2*() logging APIs. The requirements for this interface are:

  • The PPS service must be running. It can be started after slogger2; slogger2 waits a few minutes for it.
  • The pps_path must be present in the PPS directory hierarchy.

The slogger2 manager then creates (or opens) a PPS object called pps_path/verbose. You can then change the verbosity level from the command line by typing:

echo buffer_set_name::verbosity_level >> pps_path/verbose

The verbosity_level is the numeric value corresponding to the severity levels defined in <sys/slog2.h>.

(QNX Neutrino 7.0 or later) Force slogger2 to look up an environment variable called SLOG_BUFFER_SIZE in each client to possibly override the buffer size associated with the -s option for that client only. The value of SLOG_BUFFER_SIZE is the desired buffer size in bytes.

This option is intended for debug use only; if you use it, slogger2 must retain all root process abilities.

-s size
(QNX Neutrino 7.0 or later) Allocate each client using the legacy logger APIs (i.e., slogb(), slogf(), slogi(), and vslogf()) a private logging buffer that's managed by slogger2 on its behalf. This option lets you override the default per-client buffer size of 16 KB. The size is in bytes, but you can specify a (case-sensitive) suffix of k to specify a size in kilobytes. To disable the legacy logging feature, set the size to 0.
-U string
Once running, run as the specified user, so that the program doesn't need to run as root. The string can be in one of these forms:
  • uid[:gid[,sup_gid]*]
  • user_name[,sup_gid]*

In the second form, the primary group is the one specified for user_name in /etc/passwd.

Be verbose; more v characters cause more verbosity.


The slogger2 daemon is the central manager of a system-logging framework. Its primary goals are to:

  • The log currently supports only text messages, not binary data.
  • (QNX Neutrino 7.0 or later) If you want to redirect syslogd output to slogger2, send the log messages to /dev/console (which slogger2 monitors) by doing one of the following:
    • Edit /etc/syslog.conf and specify an action that sends the logs to /dev/console, and then start syslogd.
    • Specify the LOG_CONS flag when you call openlog()

The components of the system logger include:

libslog2, <sys/slog2.h>
The library and header file for the API.
The daemon process that's responsible for:
  • allocating buffers for each process
  • maintaining buffers (cleaning up buffers when processes die, etc.)
  • controlling verbosity
  • gathering logs
  • providing a means for other components to consume the logs
libslog2parse, <slog2_parse.h>
A library that supports log parsing by other tools (e.g., slog2info). For more information, see slog2_parse_all(), slog2_parse_dynamic_buffer(), slog2_parse_static_buffer(), and their related functions in the C Library Reference.
The realtime viewer. It can consume the live stream from slogger2, as well as parse (using libslog2parse) and display saved slog2 files.

Buffer Management

The central slogger2 process manages a region of shared RAM where all slog2 buffers are located. This gives slog2 the performance benefit of writing to RAM (instead of to flash or disk) without losing logs in the case of process crashes. When a process ends, its logs remain in RAM, but slogger2 removes them when it needs to reuse that memory. However, if the power source is disconnected, any log contents in RAM will be lost.

Individual slog2 instances are allocated from this memory region by slogger2 and are provided to the client process, via slog2_register(), in the form of a shared memory file in /dev/shmem/slogger2/. The libslog2 library uses shmem_open() to access each instance.

Within each slog2 instance there may be up to four buffers defined by the client process. These buffers can be any combination of 4 KB pages. The primary intent for these buffers is to enable high-rate logging into one buffer, while preserving a longer history of low-rate logging in another.

Note: The intent isn't for every subcomponent in a client process to have its own buffer. Each buffer introduces overhead, both in memory management and in terms of log-streaming performance. The expectation is that it will be rare for more than two buffers in a single instance to be used. For extreme situations, the client process can register multiple slog2 instances to satisfy a need for additional buffers.

The central slogger2 process is responsible for cleaning up the slog2 instances, including calling the shmem_unlink() function to remove the shared memory file.

Severity, verbosity, and filtering

Each log line is assigned one of the following severity levels (listed here in decreasing order):

Shut down the system now (e.g., for OEM use).
Unexpected unrecoverable error (e.g., hard disk error).
Unexpected recoverable error (e.g., you need to reset a hardware controller).
Expected error (e.g., parity error on a serial port).
Warning (e.g., out of paper).
Information (e.g., printing page 3).
Debug messages (e.g., normal detail).
Debug messages (e.g., fine detail).

The verbosity level controls which log lines are written in the slog2 buffer; if the severity level is greater than the verbosity level, the line is written in the buffer.

Filtering controls which log items are displayed to the user; the log contents aren't affected. You could filter the log by using (for example) grep, slog2info, or a custom log viewer.