From owner-freebsd-questions Sun Jan 30 20:25:19 2000 Delivered-To: freebsd-questions@freebsd.org Received: from sblake.comcen.com.au (sblake.comcen.com.au [203.23.236.144]) by hub.freebsd.org (Postfix) with ESMTP id AA55E14EDF for ; Sun, 30 Jan 2000 20:25:14 -0800 (PST) (envelope-from aunty@sblake.comcen.com.au) Received: (from aunty@localhost) by sblake.comcen.com.au (8.9.3/8.9.3) id PAA46918; Mon, 31 Jan 2000 15:26:39 +1100 (EST) (envelope-from aunty) Date: Mon, 31 Jan 2000 15:26:39 +1100 From: aunty To: Tony Simaz Cc: Jim Conner , freebsd-questions@FreeBSD.ORG Subject: Re: syslogd stops Message-ID: <20000131152639.A46733@comcen.com.au> References: <4.2.0.58.20000107134842.009b7f00@mail.enterit.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, Jan 08, 2000 at 05:48:01PM -0500, Tony Simaz wrote: > On Fri, 7 Jan 2000, Jim Conner wrote: > > > path_to_pid_file > > This optional field specifies the file name to read to find the > > daemon process id. If this field is present, a signal_number is > > sent the process id contained in this file. This field must > > start with "/" in order to be recognized properly. > > > > I haven't checked this out a lot but this may be the problem on your > > machine. It may not be correctly killing the PID for syslogd before moving > > that log file out from underneath the FD. This seems the be the problem to > > me. Im just stabbin in the dark though :) > > > > Im really curious to see if we can resolve this. Let me know if any of this > > is any help. > > > > Jim > > I would say that is a very accurate stab though. On that machine that > has the problem I DID change when newsyslog runs. I did not change it > in the daily script though. > > I will definitly take a long hard look at this on Monday. Did you find anything, Tony? As I reported before, one of my two logging machines has just the defaults in newsyslog.conf, and the problem occurs on both of them. Over the past few days I've upgraded to -STABLE and it still happens. Maybe I can stop it happening by playing with newsyslog.conf, telling it to kill syslogd stone dead and restart (the only way that fixes this problem) instead of using SIGHUP (the default, always worked before). The silence so far seems to indicate that (please correct if wrong) - on 3.3-RELEASE, 3.4-STABLE, and probably earlier versions too - if (and only if?) the machine receives logs from other machines - and including instances of machines using the default config files Occasionally syslogd will stop writing log entries to the logs, but will still write the "log rotated" note each day. This failure seems to occur, if at all, at a time when newsyslog is rotating the logs, and once it has happened it continues to malfunction without ever any complaint. NO SIGHUP will restore syslogd which is quite alive and apparently healthy, only a total kill and restart will set it right. If the above is what's happening, either the default newsyslog.conf needs tweaking, or a warning needs to be put in some docco or config, or there is some problem with one of the programs that needs looking into. Operator error seems most likely, but what? where? how? This thread and others like it over the past couple of years haven't come up with a complete explanation or a solution as far as I can see. I'm about to investigate logging to a different OS, abandoning this thread too. So how about this: Is there anyone running a logging machine on a pretty vanilla setup who has NOT ever had this problem? === I wrote the above a couple of weeks ago, postponed it and forgot about it. Today a workmate reported the same thing, syslog stops logging, on a fairly vanilla FreeBSD 3.3-RELEASE system, with unaltered newsyslog.conf. This one is different, though. Unlike the others who have reported trouble, his machine does not and never has been used to receive logs from other machines. (Yes, his machine's date is set to tomorrow) [ end of ls -lart ] -rw-r----- 1 root wheel 2694 Jan 30 02:03 dmesg.today -rw-rw-r-- 1 root wheel 1175 Jan 30 17:00 maillog.1.gz -rw-rw-r-- 1 root wheel 3984 Jan 31 17:00 maillog.0.gz -rw-rw-r-- 1 root wheel 58 Jan 31 21:00 messages -rw-rw-r-- 1 root wheel 11076 Jan 31 21:00 messages.0.gz -rw-r--r-- 1 root wheel 2550 Jan 31 22:05 wtmp.Jan.gz -rw-r----- 1 root wheel 15373 Feb 1 02:03 setuid.today drwxr-xr-x 2 root wheel 1024 Feb 1 05:30 . -rw-r--r-- 1 root wheel 3612708 Feb 1 09:29 apache_error_log -rw-r--r-- 1 root wheel 455771 Feb 1 09:29 apache_ssl_engine_log -rw-r--r-- 1 root wheel 127370 Feb 1 09:29 apache_ssl_request_log -rw-rw-r-- 1 root wheel 9071 Feb 1 13:43 maillog -rw-r--r-- 1 root wheel 4261440 Feb 1 13:45 apache_access_log -rw-rw-r-- 1 root wheel 28112 Feb 1 13:46 lastlog -rw-r--r-- 1 root wheel 352 Feb 1 13:46 wtmp -rw-rw-r-- 1 root wheel 616 Feb 1 13:54 sendmail.st bash-2.03# cat /var/log/messages Jan 31 21:00:00 naan newsyslog[9050]: logfile turned over bash-2.03# date Tue Feb 1 13:58:28 EST 2000 bash-2.03# uname -a FreeBSD naan.comcen.com.au 3.3-RELEASE FreeBSD 3.3-RELEASE #0: Thu Sep 16 +23:40:35 GMT 1999 jkh@highwing.cdrom.com:/usr/src/sys/compile/GENERIC i386 It seems that people who collect logs from several other machines don't suffer fro this more often, they just notice the problem and scream louder. And there really does seem to be an unsolved problem. -- Regards, -*Sue*- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message