... here paper bag! here boy!
Duh. That is just syslog() catching SIGPIPE inside itself.
Two different tests I did using strace on `logger':
#1, while the syslog daemon is listening, #2 while it is dead:
[#1]
...
rt_sigaction(SIGPIPE, {0x400e73a0, [], 0}, {SIG_DFL}, 8) = 0
socket(PF_UNIX, SOCK_DGRAM, 0) = 1
fcntl(1, F_SETFD, FD_CLOEXEC) = 0
connect(1, {sun_family=AF_UNIX, sun_path="/dev/log"}, 16) = -1 EPROTOTYPE (Protocol wrong type for socket)
close(1) = 0
socket(PF_UNIX, SOCK_STREAM, 0) = 1
fcntl(1, F_SETFD, FD_CLOEXEC) = 0
connect(1, {sun_family=AF_UNIX, sun_path="/dev/log"}, 16) = 0
send(1, "<13>Feb 2 12:29:57 logger: test"..., 33, 0) = 33
rt_sigaction(SIGPIPE, {SIG_DFL}, NULL, 8) = 0
[#2]
...
rt_sigaction(SIGPIPE, {0x400e73a0, [], 0}, {SIG_DFL}, 8) = 0
socket(PF_UNIX, SOCK_DGRAM, 0) = 1
fcntl(1, F_SETFD, FD_CLOEXEC) = 0
connect(1, {sun_family=AF_UNIX, sun_path="/dev/log"}, 16) = -1 ECONNREFUSED (Connection refused)
close(1) = 0
rt_sigaction(SIGPIPE, {SIG_DFL}, NULL, 8) = 0
Based on previous tests the daemon must be there, but not necessarily
reading data on the socket. I suppose a blocking send() inside syslog()
and a backed-up buffer to the socket and in turn over to the dameon
might explain the symptoms.
I was in error about a previous statement too -- that restarting the
syslog daemon wouldn't fix the problem. If the client is already wedged
in the send() inside syslog(), it won't help. That is what I was talking
about at the time, but isn't generally true.
If you just HUP the syslog daemon, that won't help either. Killing and
restarting the daemon will cause the client (the syslog()-using program)
to get a SIGPIPE and reset the connection, which will fix everything
until the next time.
So, it is definitely high-time to stare at the syslog daemon. It hasn't
changed since Oct 15 `98 when I got it (sysklogd-1.3-27), but what is
has been linked against has.
--- john
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/