Scaling Syslogd2 Down

(CAP_SINGLEPOOL, CAP_SINGLETHREAD and CAP_SINGLEPORT)


Home Page

Configure Syslogd2

Sample Files

Deployment

New Concepts

The Config File

Compile & Install

Misc Topics

Capabilities

Minimize Resources

CAP_SINGLEPOOL
CAP_SINGLETHREAD
CAP_SINGLEPORT

Demonstrations

Reference

Glossary of Terms

External Links

Syslogd2 Project Site
DBD2 Home Page
DBD2 Project Site

Other References

RFC 3164 (The BSD Syslog Protocol)
RFC 3339 (Internet Time Format)
RFC 5424 (Syslog Version 1)

Focus on Network

Syslogd2 Input Options
Syslogd2 Output Options
Queueing and Data Loss

CAP_SINGLEPOOL

[Top of page]

When the CAP_SINGLEPOOL compiler symbol is defined, Syslogd2 forces every connection and threadmaps threadpool-identifier to 0 [zero] during startup. This effecively limits every type of threadpool to no more than 1 [one] instance. Note that the ability to declare additional threadpool-types is not affected nor is the ability for the single threadpool to declare multiple threads - just the number of threadpool-instances of each threadpool type.

By default (with no other declarations), Syslogd2 creates only one threadpool of the socket type. All other threadpool types need additional declarations:


When I originally implmented these 3 'CAP_SINGLE*' features, my intent was to allow Syslogd2 to scale down as well as up, though I struggle to find a use for these three options outside of a desire to hard-code strict resource limits into Syslogd2 for some reason.

The best I've come up with is that administrators may choose to declare this option for those laptop (or work-from-home users) -- every organization has them -- that demand root access for 'their' company-provided linux-based PC, then proceed to use that root access to alter system services and other settings, ultimately resulting in a service call because their loptop "mysteriously stopped working".

Since laptops rarly produce large amounts of log data, one threadpool in Syslogd2 should be more than enough to handle that user's syslog traffic.

CAP_SINGLETHREAD

[Top of page]

When the CAP_SINGLETHREAD compiler symbol is defined, Syslogd2 forces every threadpool's thread-count value to 1 [one] for every threadpool-type. When combined with the effects of the CAP_SINGLEPOOL declaration, (and assuming no additional threadpool types have been declared, this setting results in the absolute minimum resource allocation Syslogd2 can support which is 2 threads (one parent thread and one child (socket) thread to process input.

CAP_SINGLEPORT

[Top of page]

The name of this declaration is not the most accurate, but I view these three compiler symbols as a 'set' and have not come up with a better name.

CAP_SINGLEPORT causes Syslogd2 to reject any and all user-specified socket-type input ports other than the 2 (two) default purts defined for syslog daemon input. These poarts are

Note that this only restricts socket input. It is still possible to define and use other types of input threadpools (kernel, tailfile, named-pipes), but they too can be disabled with a compile-time settingg (or rather by omitting a compile-time declaration).

An unnecessary word of caution is in order here: If you declare CAP_SINGLEPORT and no other threadpool types, then you either do not enable IP or you disable the default IP port and if you then also disable the default linux port, Syslogd2 will not run as you will have disabled all it's possible input sources -- so what would be the point ?

~ --disable inet
~ --disable defaultip, syslog ## disable the default IP port and the default Linux port.