335059 |
13-Jun-2018 |
ed |
MFC r309925, r309931, r309933, r310035, r310278, r310310, r310311, r310323, r310349, r310350, r310351, r310352, r310383, r310384, r310385, r310386, r310393, r310453, r310456, r310494, r310504, r310528, r310890, r310893, r310974, r311918, r312921, r313357, r314563, r314585, r314642, r315322, r315618, r315620, r315622, r315643, r316951, r316973, r326338, r326339, r326573, r331270, r332099, r332110, r332111, r332118, r332165, r332510 and r332511.
This commit brings syslogd(8) in sync with the copy in HEAD. The key improvement of this change is that it adds support for RFC 5424 log ingestion and exposition (enabled by passing in -O rfc5424). This allows for saner logging in environments with multiple time zones.
The list of changes to merge back were obtained by running:
svn mergeinfo --show-revs eligible \ ^/head/usr.sbin/syslogd ^/stable/11/usr.sbin/syslogd
Of the commits listed, r314436, r325188 and r326025 were excluded, as they affect a significant number of unrelated files (SPDX and 4-clause license renumbering). Due to the large number of directly committed changes on this branch, I had no choice but to perform the merge as follows:
svn merge --accept=theirs-full -c <list of revisions> ^/head .
This would, however, cause some unrelated changes, such as undoing the r333356 (MFC of r332877) and still adding the SPDX tag to syslogd.c. These have been reverted manually.
Requested by: Dave Cottlehuber Thanks to: dim@ for sharing his insight on hackers@ |
217589 |
19-Jan-2011 |
dwmalone |
Here v->iov_len has been assigned the return value from snprintf. Checking if it is > 0 doesn't make sense, because snprintf returns how much space is needed if the buffer is too small. Instead, check if the return value was greater than the buffer size, and truncate the message if it was too long.
It isn't clear if snprintf can return a negative value in the case of an error - I don't believe it can. If it can, then testing v->iov_len won't help 'cos it is a size_t, not an ssize_t.
Also, as clang points out, we must always increment v here, because later code depends on the message being in iov[5].
|
57558 |
28-Feb-2000 |
joerg |
Fix a serious bug in syslogd regarding the handling of pipes. The bug would cause syslogd to eventually kill innocent processes in the system over time (note: not `could' but `would'). Many thanks to my colleague Mirko for digging into the kernel structures and providing me with the debugging framework to find out about the nature of this bug (and to isolate that syslogd was the culprit) in a rather large set of distributed machines at client sites where this happened occasionally.
Whenever a child process was no longer responsive, or when syslogd receives a SIGHUP so it closes all its logging file descriptors, for any descriptor that refers to a pipe syslogd enters the data about the old logging child process into a `dead queue', where it is being removed from (and the status of the dead kitten being fetched) upon receipt of a SIGCHLD. However, there's a high probability that the SIGCHLD already arrives before the child's data are actually entered into the dead queue inside the SIGHUP handler, so the SIGCHLD handler has nothing to fetch and remove and simply continues. Whenever this happens, the process'es data remain on the dead queue forever, and since domark() tried to get rid of totally unresponsive children by first sending a SIGTERM and later a SIGKILL, it was only a matter of time until the system had recycled enough PIDs so an innocent process got shot to death.
Fix the race by masking SIGHUP and SIGCHLD from both handlers mutually.
Add additional bandaids ``just in case'', i. e. don't enter a process into the dead queue if we can't signal it (this should only happen in case it is already dead by that time so we can fetch the status immediately instead of deferring this to the SIGCHLD handler); for the kill(2) inside domark(), check for an error status (/* Can't happen */ :) and remove it from the dead queue in this case (which if it would have been there in the first place would have reduced the problem to a statistically minimal likelihood so i certainly would never have noticed the bug at all :).
Mirko also reviewed the fix in priciple (mutual blocking of both signals inside the handlers), but not the actual code.
Reviewed by: Mirko Kaffka <mirko@interface-business.de> Approved by: jkh
|