[ On Tuesday, September 26, 2000 at 15:05:24 (-0700), regs@zembu.com wrote: ]
> Subject: bin/11087: syslogd not working, HUP doesn't fix, requires hard restart
>
> 	Our machine has been up for a while.  About 2 weeks ago (see 
> 	logfile excerpt) log data stop appearing the logs.  I attempted to
> 	HUP syslog, which generated a restart line in /var/log/messages. 
> 	Still, no log data.  A hard restart fixed it.

A "hard" restart of syslogd alone, or a full reboot of the system?

Long-running local processes that only call openlog() once at their
initialisation will not continue to log after syslogd has been restarted
because they use local-domain sockets to communicate with syslogd and it
would seem that there's no existing mechanism in use to signal when a
the syslogd has gone away, and since syslogd does the further injustice
of re-creating the pathname representing the local-domain socket
(i.e. _PATH_LOG, or /var/run/log) every time it starts up, it's probably
necessary to re-open the client-side socket too.  Note how different
this is semantically from normal "datagram" style sockets where you can
always just blindy spew stuff out and hope somone is still listening!

Maybe fixing the latter could be as simple as this (this is pure
un-tested speculation though):

Index: syslog.c
===================================================================
RCS file: /cvs/NetBSD/src/lib/libc/gen/syslog.c,v
retrieving revision 1.1.1.5
diff -c -u -r1.1.1.5 syslog.c
cvs diff: conflicting specifications of output style
--- syslog.c    2000/09/22 04:11:05     1.1.1.5
+++ syslog.c    2000/09/27 06:17:47
@@ -251,7 +251,9 @@
	if (send(LogFile, tbuf, cnt, 0) >= 0) {
		mutex_unlock(&syslog_mutex);
		return;
-       } 
+	} else {
+	       closelog();
+       }
	mutex_unlock(&syslog_mutex);
 
	/*


-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>