ConnectionManagement

Return to Home page

Syslogd2 Connection Recovery and Reconfiguration

Contents:

General Concepts

Actions Specific to Input Connections

Actions Specific to Output Connections

Return to top

General Syslogd2 Concepts Regarding Connection Recoery, Management & Reconfiguration

Return to top
Syslogd2 supports 5 levels of "connection-management" based on 4 run-time parameters and one compile-time CAP_* declaration:

Traditional: This level is in effect when:

SourceCheckIntervals is disabled.
DestinationCheckIntervals is disabled.
CheckReconfigIntervals is disabled.
CAP_RECONFIG compile-time declaration is not defined.

Managed Connections: This level is in effect when:

SourceCheckIntervals is enabled.
DestinationCheckIntervals is enabled.
CheckReconfigIntervals is disabled.
CAP_RECONFIG compile-time declaration is not defined.

Delayed Resolution: This level is in effect when:

SourceCheckIntervals is enabled.
DestinationCheckIntervals is enabled.
CheckReconfigIntervals is enabled.
CAP_RECONFIG compile-time declaration is not defined.

Basic Reconfiguration: This level is in effect when:

SourceCheckIntervals is enabled.
DestinationCheckIntervals is enabled.
CheckReconfigIntervals is enabled.
CAP_RECONFIG compile-time declaration is defined and the global Reconfig boolean value is globally disbaled.

Advanced Reconfiguration: This level is in effect when:

SourceCheckIntervals is enabled.
DestinationCheckIntervals is enabled.
CheckReconfigIntervals is enabled.
CAP_RECONFIG compile-time declaration is defined and the global Reconfig boolean value is globally enabled.

More information about the three schedules mentioned above can be found here.
Each of the three schedules mentioned above is associated with a specific subroutine name. Each subroutine can be assigned (by name) to one of the 4 Syslogd2 command-tool (tsuc*) without needing to dedicate an interrupt setting.

The SourceCheckIntervals parameter configures run-time intervals for the CheckSources subroutine.
The DestinationCheckIntervals parameter configures run-time intervals for the CheckDestinations subroutine.
The ReconfigCheckIntervals parameter configures run-time intervals for the CheckReconfig subroutine.

Of the three subroutines under discussion, CheckReconfig is a special-case. Its schedule is not directly used to determine or schedule start-times if either CheckSources or CheckDestinations has an active schedule. This is to avoid conflict. Because CheckReconfig is actually a component of the reconfiguration subsystem, and because it supports other features, the CheckReconfig routine's schedule (if not disabled) will be invoked directly if whenever both Check&Sources and CheckDestinations (Check* collectively) are disabled or suspended.

CheckReonfig will usually be called as a "pre-processor" by "Check*" routines if it is (1) schedule-enabled and (2) schedule-ready (not within the scheduled minimum time-interval between successive executions of CheckReconfig).
"Pre-processor" means that CheckReconfig is called before any work is done by CheckSources or CheckDestinations - both to avoid internal resource conflicts and so that when they DO run, CheckSources and CheckDestinations will always be working with the latest confgiuration. The return value from CheckReconfig is checked to see if the calling routine should continue working or abort operations because a major reconfiguration has been scheduled and there is no sense in delaying that reconfiguration by waiting for a Check* routine to finish.
Each of the three sub-outines re-schedules their next "earliest run-time" at the conclusion of each execution cycle.

CheckSources: This routine walks the global list of input-source structures, checking the status of each input source and attempting to re-open any closed inputs.

For tailfile inputs, it checks to see that the file is resolved, exists and is currently open for read. A tailfile is resolved when the directory it resides in exists in the filesystem.
If the file is "resolved", CheckSources then verifies that the file exists on disk, it also checks to see that the file has been opened (CheckSources opens it if not). If the file is closed or in an error-state (such as deleted or a non-file such as a directory, socket or pipe), one attempt will be made to open it. An input tailfile will be closed after it has failed at least one attempt to re-open it. A single re-open attmept by CheckSources allows for file rotation or resets without causing performance issues by constantly attempting to open a missing file. - especially one on a missing filesystem-mount resulting from a 'down' remote host. For any file that is successfully re-epened, CheckSources resets the schedule index & clears all error-flags for the file, returning it to an 'active / available' state. CheckSources then checks the status of the applicable threadpool and will "awaken" any threadpool that was "put to sleep" because none of its defined files could be found or opened.
For Linux Socket inputs, CheckSources checks that the socket is resolved, is open and if the filesystem entry for the socket exists. A Linux Socket is resolved when the filesystem directory containing its filesystem entry exists.
If the filesystem entry is missing, the socket is closed and reopened (thereby re-creating the filesystem entry). If the socket had been closed, it is re-opened. For any Linux Socket that is successfully re-opened, CheckSources clears all error-flags for the socket, returning it to an 'active / available' state.
Syslogd2 attempts to re-open a closed Linux socket one time only. This is usually enough to re-open the socket unless a persistent problem (such as file permissions) exists. whenever a Linux socket is successfully re-opened, CheckSources will check the status of the associated input threadpool and will "awaken" the threadpool if it had been "put to sleep" due to lack of valid sockets to monitor. For IP Socket inputs, CheckSources checks to see if OS recognizes the IP socket as open. If the socket had been closed for any reason (such as an interface reset or service interruption), CheckSources will re-open the socket, clear the error-status-flags and return the socket to use.
An IP input socket is resolved when the hostname or address has been found on any active network interface.
Some network stacks (such as MAC OSX's implementations of IPv6) may not recognize all addresses assigned to the interfaces, resulting in Syslogd2 rejecting source IP addresses. To fix this, use Syslogd2's --defaults selfaddress=... option. This option tells Syslogd2 that the applicable address is on an interface and can be resolved.
whenever an IP socket is successfully re-opened, CheckSources will check the status of the associated input threadpool and will "awaken" the threadpool if it had been "put to sleep" due to lack of valid sockets to monitor.

Return to top

Return to Home page