slogger2

System logger

Syntax:

slogger2 [-p pid] [-U string] [-v[v]...]

Runs on:

QNX Neutrino

Targets:

ARM, x86

Options:

-p pid

(Debugging only) Run as the given client process ID.

-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.

-v[v]...

Be verbose; more v characters cause more verbosity.

Description:

The slogger2 daemon is the central manager of a system-logging framework that overcomes various limitations of the legacy slogger system. The primary goals for slogger2 are to:

provide high performance
work in situations where interrupts aren't enabled
provide component-specific log buffers and verbosity control

Note: The log currently supports only text messages, not binary data.

(QNX Neutrino 6.6) You can't redirect slogger output to slogger2 in general, but if a program uses the slogger APIs, you can preload the libslog2shim.so library when you start the program, in order to redirect its logs:

LD_PRELOAD=libslog2shim.so my_program

The components of the system logger include:

libslog2, <slog2.h>

The library and header file for the API.

slogger2

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.

slog2info

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):

SLOG2_SHUTDOWN: Shut down the system now (e.g., for OEM use).
SLOG2_CRITICAL: Unexpected unrecoverable error (e.g., hard disk error).
SLOG2_ERROR: Unexpected recoverable error (e.g., you need to reset a hardware controller).
SLOG2_WARNING: Expected error (e.g., parity error on a serial port).
SLOG2_NOTICE: Warning (e.g., out of paper).
SLOG2_INFO: Information (e.g., printing page 3).
SLOG2_DEBUG1: Debug messages (e.g., normal detail).
SLOG2_DEBUG2: 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.