CAP_KERNELTHREADS

Return to Home Page

Contents:

Reading Kenel Input

CAP_KERNELTHREADS

Reading Kernel Input

Return to top
Kernel information can be a treasure-trove of syslom-management information. It can also be a major source of frustration for administrators. The difference lies in how the information is handled and the tools that pre-process the raw information into useful informational alerts.

Linux and Unix kernel data is at once both very valuminous and indispensibly valuable for host-system administrators. Kernel data contains notifications of panic-conditions and less-urgent hardware failures such as disk errors or memory chip failures that today's hardware can recover from, but that indicate un-recoveable errors may be imminent. In addition to imminent hardware failures, kernel data often contains security information (user-login information, reports of USB sticks being inserted / removed, failed login attempts indicating potential unauthorized access, etc).

Syslogd2 provides multiple means of importing (reading) kernel data -- either local Kernel data or from mounted filesystems that contain kenel log files from other platforms. There are two primary methods useable to obtain kenel data on Linux platforms: (1) Use system-calls to read the kernel's syslog-buffer directly (without the need to mount the /proc filesystem) or (2) tail the kernel pseudo-log-file /proc/kmsg.

Syslogd2 is designed to support both methods. (Syslogd2 components that have not yet been implemented are listed in red.)

In Syslogd2:

1. Kernel logging is enabled by default. To change any parameter from default values, the user must specify a --kernel command-line option with the desired parameters. Default Parameters are (an incomplete list):

System-defined file at /proc/kmsg. This file specification can be changed with the --defaults klogfile = <filepath> command-line option.
Non-polling method (either CAP_KERNELTHREADS system-calls or inotify socket-notifications).
No filters.
Default threadpool-id of 0.
Default priority for lines without embedded priorities: kern.notice.

2. The global boolean value kernellog will administratively disable all kernel input.
3. Syslogd2 provides 3 mechanisms to read Linux-kernel input:

(1): CAP_KERNELTHREADS provides both a direct-kernel-system-call method and a polling algorithm if declared at compile-time and not disabled at run-time with --disable kernelthreads.
(2): The filesystem socket-notification facility (inotify) of modern Linux filesystem(s) provides notification of file updates.
(3): CAP_TAILFILES provides generic polling for ASCII text files and can be used with the --kernel command-line option to read the /proc/kmsg (or other deignated) file for kernel input.

4. The hierarchy of options Syslogd2 uses to choose a method to read kernel data is as follows:

If CAP_KERNELTHREADS is declared and not disabled with --disable kernelthreads:

The default method will be to use system-calls to read the kernel's buffer. This has the side-effect of disabling the /proc/kmsg file.
To get the alternate action (kernel-reader-threads polling the file), provide a --kernel command-line option with the poll sub-option.

If CAP_KERNELTHREADS is not declared or is disabled with --disable kernelthreads, the default is to use inotify if supported on the applicable filesystem. This default behavior can be modified with the poll option to a --kernel command-line option to force polling with the CAP_TAILFILES algorithms instead.
If inotify is not supported by the filesystem, then if CAP_TAILFILES is declared, the poll option will be added as a "last resort" to the default kernel specification or to any user-specified --kernel option.

Syslogd2 can also provide an ability to read the local system's kernel input and to simultaneously read one or more additional (mounted) kernel or other files from other hosts.

To configure this ability, enable the CAP_TAILFILES feature at compile-time, then (with filesystems mounted), configure standard --tailfile options:

~ --tailfile = filepath>, facility = kern, hostname = source-host

The facility parameter above over-rides the default (user.notice) facility, forcing all input facility components to "kern".
The hostname parameter "fakes" the hostname on input so that all traffic from that file appears to have originated from the host whose kernel file is being monitored. This is a polling algorithm not dependent on any unique facilities or Linux services so it should work over any type of remote mount (nfs, CIFS, etc).

Getting data into the system is only part of the problem of using Linux and Unix kernel data for host-management. Use Syslogd2's input and output filters to get granular control over message routing and over which messages get dropped and which get forwarded for action. Syslogd2's extra* facilities can be used to assist in segregating and routing traffic to as many destinations as necessary.
Return to top

CAP_KERNELTHREADS

Return to top
The CAP_KERNELTHREADS capability has not yet been implemented.

When it is implemented, CAP_KERNELTHREADS will provide a new threadpool type that can be disabled at runtime with --disable kernelthread. This threadpool type will offer two methods to read Linux kernel data as an alternative to (or in addition to) declaring CAP_TAILFILES. When declared and enabled, the CAP_KERNELTHREAD threadpool will be used to read kernel data. The procfs value to the --kernel command-line option will select the polling option. The default will be system-call. The new kernel-threadpool will:

1. Poll the /proc/kmsg file without needing to declare CAP_TAILFILES.
2. Directly read the kernel's syslog ring-buffer via system call (removing the need to mount /proc to read kernel log data).

Until the CAP_KERNELTHREADS functionality is implemented, the work-around is to use CAP_TAILFILES. Use of CAP_TAILFILES will remain the alternative to CAP_KERNELTHREADS for kernel input. Likewise, CAP_KERNELTHREADS will provide alternative kernel access when CAP_TAILFILES is not declared.
Return to top

Return to Home Page