user unless they come directly from the kernel. Document this and
add a flag to syslogd which prevents this conversion.
Sort getopt args while I'm at it.
PR: 21788
Submitted by: Andre Albsmeier <andre.albsmeier@mchp.siemens.de>
Remove extra parens from my host selection commit.
Add white space after if, while, for and switch.
Get rid of braces around a single statement if.
There should be no functional changes in this commit.
Reviewed by: sheldonh
a similar way to the way it can select messages from a given program.
Lines beginning with "+hostname" or "#+hostname" select messaes
from that hostname and lines beginning with "-hostname" or "#-hostname"
match messages not from that hostname.
There are some significant style issues left in the original program
selection code and the man page. This should be cleared up in some
later commits.
Reviewed by: sheldonh
Based on an original patch by: Bernd Walter <ticso@cicely8.cicely.de>
Man page stylist: sheldonh
as they ought to be. The description of SA_RESTART was a little
unobvious to me in the man page, so i missed it. Thanks to Bruce for
spotting this.
Submitted by: bde
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
vogons, set the size of the receive buffer to 1 and rely on the kernel to
simply drop incoming packets. The logging code was buggy anyway.
Use socklen_t instead of int for the length argument to recvfrom.
Add a 'continue' at the end of a loop for ANSI conformance.
should be used from now on for anything security but not auth-related.
Included are updates for all relevant manpages and also to /etc files,
creating a new /var/log/security. Nothing in the system logs to
/var/log/security yet as of the time of this commit.
Reviewed by: rgrimes, imp, chris
-current (Thanks Harald). However, on my attempt to try this on -STABLE,
I found that when forwarding to another host the actual messages gets lost.
This is due to a wrong index because when the -v option was added, the
indexes shifted one place.
PR: 7407
Submitted by: Andre Albsmeier <andre.albsmeier@mchp.siemens.de>
This allows one to specify additional sockets in the unix domain
that syslogd listens to. Its primary use is to create log sockets in
chroot environments.
Obtained from:OpenBSD (with a bug fixed d
category.
e.g. separate out ipfw entries to a separate file.
Reviewed by: (briefly) phk
Submitted by: archie@whistle.com
Obtained from: Whistle source tree
This change is likely to introduce a few linebreaks in the boot
messages, but that is not easy to solve without breaking syslogd
semantics. Maybe the right fix is to return an integral number
of lines from the kernel driver.
Noticed by: dg
It is important that we keep the ability to send packets to a remote
server and that the packets come from our well-known port, also in
that case.
Reviewed by: peter, rgrimes.
found that my syslogd is now running them for several months...
Add an option to syslogd to restrict the IP addresses that are allowed
to log to this syslogd. It's too late to develop the inter-syslogd
communications protocol mentioned in the BUGS section, some 10 years
too late. Thus, restricting the IP address range is about the most
effective change we can do if we want to allow incoming syslog
messages at all.
IMHO, we should encourage the system administrators to use this option,
and thus provide a knob in /etc/rc.* for it, defaulting to -a 127.0.0.1/32
(just as a hint about the usage).
Please state opinions about whether to merge this change into 2.2 or
not (i've got it running on RELENG_2_2 anyway).
stable now at a customer's site.
Finally add the ability to syslogd to pipe particular messages through
an arbitrary filtering command. Idea stolen from IRIX.
This code is courtesy of the interface business GmbH, Dresden.
Comment about whether to also merge this into 2.2 or not, please.
Reviewed by: (long ago) peter
This will make a number of things easier in the future, as well as (finally!)
avoiding the Id-smashing problem which has plagued developers for so long.
Boy, I'm glad we're not using sup anymore. This update would have been
insane otherwise.
bug in syslogd which causes it to die after random amounts of time (widely
reported), this at least allows the administrator to easily restart it
without wondering why it simply exits again each time.
has always held an open file descriptor. This allowed logging to
spare virtual consoles and being able to switch to them.
My previous change removed this since all writes were done with ttymsg()
which opens it's own fd, and hence syslogd didn't need it's own fd to
send messages on... but this caused an unexpected behavior change.
This should close PR#2176
ttymsg() insists on them not being there.
Also, since ttymsg() opens the tty "on demand", don't keep an fd open
ourselves. This would interfere with HUPCL etc.
This should close PR#2103 from <xaa@stack.nl>
the races in my previous commits here, and fix some other problems with
syslogd as well.
- if the child process exited early (eg: could not bind to the socket),
the boot process would hang for 30 seconds. The parent was not noticing
that the child had exited. (my fault)
- when writing to tty devices, instead of treating them like files that
need \r\n instead of \n, actually use ttymsg() which has specific code
intended to write to potentially blocking ttys safely. I had a machine
lock up last night because /dev/console on a serial port got flow control
blocked. Setting comcontrol drainwait fixed everything but syslogd which
was going into a spin trying to write to the console and completely
ignoreing everything else.
- fix a couple of nonsensical bits of code while here.. eg: wait3 takes
a pointer to an int. There is no sense in declaring it as 'union wait',
then casting the pointer to (int *), then forgetting about it.
Submitted by: whistle communications
move the socket from /dev to /var/run by default
TRANSITIONALLY make syslog add a symlink..
I PROMISE I'll remove that as soon as I have the makefiles etc fixed as well.
For me, more often than not, the backgrounded syslogd daemon is not
yet ready to process log messages before other things (such as named)
want to log a heap of them. It seems that it's the O_SYNC writes of
the stuff coming in from /dev/klog that's the slowdown.
Anyway, instead of using the libc daemon, roll a modified version. This
one has a timeout. The child will wait for either the timeout to expire
or the child process to signal it to let it know that it's "ready" and
the /dev/log socket is set up and active, so it's safe to continue the
boot. It adds a small fraction of a second pause to the boot time, but on
the other hand the overall boot time is *quicker* since the disk is not
being thrashed while the log messages are getting written out synchronously
one by one while other daemons are loading in parallel.
The timeout is in case the child segfaults or something before becoming
fully operational.
with theirs (change the -I option to -s (but leave -I in for backwards compat.)
Also eliminate an make sane some magic numbers, and fix a small bug where we'd
send to an unopened socket.
Reviewed by: wollman
Obtained from: NetBSD
`interesting' feature of syslogd turned up. It calls getbootfile() for each
log entry. Since the kernel makefile now changes kern.bootfile when doing
a 'make install', it's quite startling to see the syslog lines change.
This change makes it call getbootfile() once at startup and cache it,
saving a syscall per loop, and keeping something a little more asthetically
pleasing in /var/log/messages...
Document `-d' and `-I'. Add a BUGS section noting that
logging from UDP is an unauthenticated remote disk-filling service,
and probably should be disabled by default in the absence of some sort
of authentication.
so that it only unlinks the file if syslogd knows it created it.
If the path specified for the socket already exists then syslogd
will now exit with an "address already in use" error which is more
sensible than blindly unlinking the existing filename. This stops
syslogd -d foo/bar from unlinking foo/bar if it's a real file.
