Re: System logs are being logged to wrong files
Hi, NOTE: Kindly CC me when replying, I am not subscribed. I picked up the reply from the list archive. On Sat, 31 Oct 2009 02:15:19 +0200 Jari Fredriksson wrote: 30.10.2009 22:56, P K kirjoitti: Hi, Kindly CC me when replying, I am not subscribed. Thanks. Now: I am using Debian/Sid (sidux actually) on a i686 machine. Over the past few months, I have seen various logs being logged to the wrong files, ie, they are being logged to the xyzlog.1 file instead of the xyzlog files. For example, consider the datestamps sizes of the following files (obtained using [1], output edited): Modification Change Size Filename 2009-10-30 14:59:14 2009-10-30 14:59:14 0 auth.log 2009-10-30 16:43:18 2009-10-30 16:43:18 4901 auth.log.1 As you can see from the size and timestamps: 1. logs for auth, daemon, kern, syslog are sent to the wrong file (*.1) 2. logs for dpkg, kdm, mail, user seems to be OK. Does anyone know what may be causing such a behavior? I can provide further information, as needed. This is just a wild guess, but it seems that your logger is keeping the files open, and it was not restarted when the logrotate named the logs again. Seems that the logger had auth.log open, and Linux just keeps writing to that file (INODE) no matter if the name was changed. Thanks for the reply. So, I assume this is not a common problem. Any ways to fix / or further investigate this? Thanks, -- Regards PK -- http://counter.li.org #402424 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
System logs are being logged to wrong files
Hi,
Kindly CC me when replying, I am not subscribed. Thanks. Now:
I am using Debian/Sid (sidux actually) on a i686 machine. Over the
past few months, I have seen various logs being logged to the wrong
files, ie, they are being logged to the xyzlog.1 file instead of the
xyzlog files. For example, consider the datestamps sizes of the
following files (obtained using [1], output edited):
Modification Change Size Filename
2009-10-30 14:59:14 2009-10-30 14:59:14 0 auth.log
2009-10-30 16:43:18 2009-10-30 16:43:18 4901 auth.log.1
2009-10-30 14:59:14 2009-10-30 14:59:14 0 daemon.log
2009-10-30 16:42:28 2009-10-30 16:42:28 4402 daemon.log.1
2009-10-30 15:30:15 2009-10-30 15:30:15 792823 dpkg.log
2009-09-26 01:57:27 2009-10-01 22:10:39 402483 dpkg.log.1
2009-10-30 16:42:50 2009-10-30 16:42:50 2850 kdm.log
2009-10-30 14:59:13 2009-10-30 14:59:13 15126 kdm.log.1
2009-10-30 14:59:14 2009-10-30 14:59:14 0 kern.log
2009-10-30 16:43:06 2009-10-30 16:43:06 66030 kern.log.1
2009-10-30 14:59:14 2009-10-30 14:59:14 0 mail.log
2009-10-30 14:54:23 2009-10-30 14:59:14 158 mail.log.1
2009-10-30 14:59:14 2009-10-30 14:59:14 0 syslog
2009-10-30 16:43:06 2009-10-30 16:43:06 74072 syslog.1
2009-10-30 14:59:14 2009-10-30 14:59:14 0 user.log
2009-10-30 14:54:21 2009-10-30 14:59:14 166 user.log.1
2009-10-30 16:42:28 2009-10-30 16:42:28 15430 Xorg.log
2009-10-19 00:59:08 2009-10-19 00:59:08 16295 Xorg.1.log
As you can see from the size and timestamps:
1. logs for auth, daemon, kern, syslog are sent to the wrong file (*.1)
2. logs for dpkg, kdm, mail, user seems to be OK.
Does anyone know what may be causing such a behavior? I can provide
further information, as needed.
[1] Obtained using:
$ for i in $(ls -1 *log{,.1}); do stat --printf=%y %z %s\t%n\n $i;
done | sed 's/\.00*//g;s/[-+][0-9]\{4\}//g'
[2] Digging around the mailing lists, I found the following related
(may not be relevant) threads:
http://lists.debian.org/debian-security/2001/04/msg00041.html
http://episteme.arstechnica.com/groupee/forums/a/tpc/f/96509133/m/755007637731
http://lists.debian.org/debian-user/2006/01/msg03321.html
http://lists.debian.org/debian-devel/2004/02/msg01647.html
--
Regards
PK
--
http://counter.li.org #402424
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: System logs are being logged to wrong files
30.10.2009 22:56, P K kirjoitti: Hi, Kindly CC me when replying, I am not subscribed. Thanks. Now: I am using Debian/Sid (sidux actually) on a i686 machine. Over the past few months, I have seen various logs being logged to the wrong files, ie, they are being logged to the xyzlog.1 file instead of the xyzlog files. For example, consider the datestamps sizes of the following files (obtained using [1], output edited): Modification Change Size Filename 2009-10-30 14:59:14 2009-10-30 14:59:14 0 auth.log 2009-10-30 16:43:18 2009-10-30 16:43:18 4901 auth.log.1 As you can see from the size and timestamps: 1. logs for auth, daemon, kern, syslog are sent to the wrong file (*.1) 2. logs for dpkg, kdm, mail, user seems to be OK. Does anyone know what may be causing such a behavior? I can provide further information, as needed. This is just a wild guess, but it seems that your logger is keeping the files open, and it was not restarted when the logrotate named the logs again. Seems that the logger had auth.log open, and Linux just keeps writing to that file (INODE) no matter if the name was changed. -- http://www.iki.fi/jarif/ signature.asc Description: OpenPGP digital signature
system logs and localtime
I have a remote server at a client site that had /etc/localtime pointing to Eastern instead of Central. I have fixed this. Is there a way for this to take affect without rebooting the server? Tony Heal
RE: system logs and localtime
BTW, this is causing all my logs to report in Eastern time Tony Heal _ From: Tony Heal [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 04, 2007 5:17 PM To: debian-user@lists.debian.org Subject: system logs and localtime I have a remote server at a client site that had /etc/localtime pointing to Eastern instead of Central. I have fixed this. Is there a way for this to take affect without rebooting the server? Tony Heal
Re: system logs and localtime
Hi there, On Tue, 4 Sep 2007 Tony Heal wrote: I have a remote server at a client site that had /etc/localtime pointing to Eastern instead of Central. I have fixed this. Is there a way for this to take affect without rebooting the server? It has already taken effect. You don't need to reboot. Unless you're playing with kernels or switching hardware, you'll very rarely need to reboot a Linux box. You will probably want to reset the (date and) time. You can use the 'date' command at the root prompt. I prefer not to do it by hand, it isn't terribly accurate, and of course it doesn't maintain the clock accurately. Better to install the opennptd package: apt-get install openntpd and read the docs. You will need to tell the daemon which timeservers you want to use (low network latency to contact the servers is good) by editing the configuration file. Here's an /etc/openntpd/ntpd.conf from my desktop in England: 8 server 0.uk.pool.ntp.org server 1.uk.pool.ntp.org server 2.uk.pool.ntp.org server 3.uk.pool.ntp.org 8 Here's some background: http://tldp.org/HOWTO/Clock.html#toc1 http://www.linuxsa.org.au/tips/time.html -- 73, Ged. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: system logs and localtime
On Tue, 4 Sep 2007, Tony Heal wrote: I have a remote server at a client site that had /etc/localtime pointing to Eastern instead of Central. I have fixed this. Is there a way for this to take affect without rebooting the server? Tony Heal After you reset your time, you will have to restart any app that is logging to syslog, you should probably also restart /etc/init.d/klogd and /etc/init.d/sysklogd. After that all of you logs should have the right time. -+- 8 out of 10 Owners who Expressed a Preference said Their Cats Preferred Techno. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
etch laptop system logs me out during inactivity (X crash?)
I've seen this happening on my etch laptop more often recently (not exactly sure when I first saw it, but it has probably been within the last 3 months). I generally keep the system relatively up-to-date (almost always within a couple weeks of current testing). I typically leave my laptop on overnight, or just running while I'm doing something else -- and during this time the laptop is basically idle. After some time, I'll return to the laptop and find that it has kicked me out of my gnome session to the gdm login prompt screen. I see this in the messages file: Dec 30 09:11:50 gish gconfd (-): Received signal 15, shutting down cleanly Dec 30 09:11:50 gish gconfd (-): Exiting I've googled a bit and not found a real cause, solution, or workaround. Some folks on the Ubuntu forums thought X was crashing and gconfd was reacting to that. As I indicated, my etch system is pretty current, and 'X -version' reports version 7.1.1. I'm also running kernel 2.6.17. Anyone else seeing this? Anyone found the problem? Thanks, Rick Reynolds -- He who breaks a thing to find out what it is, has left the path of wisdom. -- Gandalf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: etch laptop system logs me out during inactivity (X crash?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, Dec 30, 2006 at 02:39:34PM -0500, Rick Reynolds wrote: I've seen this happening on my etch laptop more often recently (not exactly sure when I first saw it, but it has probably been within the last 3 months). I generally keep the system relatively up-to-date (almost always within a couple weeks of current testing). I typically leave my laptop on overnight, or just running while I'm doing something else -- and during this time the laptop is basically idle. After some time, I'll return to the laptop and find that it has kicked me out of my gnome session to the gdm login prompt screen. I see this in the messages file: Dec 30 09:11:50 gish gconfd (-): Received signal 15, shutting down cleanly Dec 30 09:11:50 gish gconfd (-): Exiting I've googled a bit and not found a real cause, solution, or workaround. Some folks on the Ubuntu forums thought X was crashing and gconfd was reacting to that. As I indicated, my etch system is pretty current, and 'X -version' reports version 7.1.1. I'm also running kernel 2.6.17. Anyone else seeing this? Anyone found the problem? Thanks, Hi Rick, There can be differnt causes: software, hardware... what video driver are you using? If you use a 'safe' driver like vesa, then it would point to a hardware issue vs using an 'unsafe' driver like a close-source driver like 'nvidia'. You can also see if its X or not by leaving X and going to the console then seeing if the laptop does anything odd after a few hours. Some folks also have issues with screen savers. Cheers, Kev - -- | .''`. == Debian GNU/Linux == | my web site: | | : :' : The Universal | 'under construction' | | `. `' Operating System| go to counter.li.org and | | `-http://www.debian.org/ |be counted! #238656 | | my keysever: pgp.mit.edu | my NPO: cfsg.org | -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFFltnov8UcC1qRZVMRAh9aAJ9u6sFMq0FXTxg2Y4V7i9aP0JHUCgCeKd+F Ui/dIQ4h23IPigFLA8wEPek= =FOam -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
can't find tcpd messages in system logs
According to various tcpd docs (manpage, READMEs) it logs information via syslog. However, when I do 'grep -i tcpd /var/log/*' I see nothing. I have tcpd 7.6.dbs-8 and sysklogd 1.4.1-17 on my machine. I have stripped my /etc/syslogd.conf down to the following single line, (and restarted inetd) and still nothing: *.debug -/var/log/debug I get messages in /var/log/debug from various other programs and daemons, but nothing I can recognize as being from tcpd. What should I be looking for in my log files? Am I looking for the wrong thing, or should I conclude that something is not working right? Or (C), none of the above? Miscellaneous possibly useful details: x86 machine running a mix of Sarge and testing packages, with a few older ones mixed in--Apt does not complain. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
No Oops in system logs
Hi, I have the following in /etc/syslog.conf: auth,authpriv.* /var/log/auth.log *.*;auth,authpriv.none /var/log/syslog cron.* /var/log/cron.log daemon.*/var/log/daemon.log kern.* /var/log/kern.log lpr.* -/var/log/lpr.log mail.* -/var/log/mail.log user.* /var/log/user.log uucp.* -/var/log/uucp.log It makes me wonder that there's no more Oops lines in syslog/messages files. I made some changes (which I don't remember); usually, the Oops got stored in some of the log files. Now, it's only on the console. What should I do so that the oops lines get stored in the logs? It's part of the kern.*, isn't it...? I already have it on the syslog.conf, as above. Thanks in advance, Oki -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: system logs not getting rotated
Thanks. With your help I have found what the problem *is*. Now I'd like to know *why* and *how* the problem came to be. The cron.daily/sysklogd script passes the argument 'reload-or-restart' to /etc/init.d/sysklogd *however* that is not one of the options in the case statement. There are only a 'reload|force-reload' and a 'restart'. The cron.daily/sysklogd script was getting a usage message which went to the bit bucket. I have never manually edited *any* of these scripts. Any changes have been done via apt-get. Woody needs to be checked to verify that the problem doesn't still exist. On Sun, Apr 07, 2002 at 12:54:20PM -0500, Mark S. Reglewski wrote: On Sun, Apr 07, 2002 at 10:50:19AM -0400, Rick Pasotto wrote: ii logrotate 3.5.9-7Log rotation utility For several weeks now my system logs have not been getting rotated. All logging is going to the .0 files. syslog, daemon.log, auth.log, etc. remain at zero length and syslog.0, daemon.log.0, auth.log.0, etc keep growing. If I reboot logging goes to the correct file until the first rotation. Is this a config problem or is there a problem with whichever program (logrotate?) does the rotating? Doesn't klogd need to be told to close the old file and open the new one? Where does that happen? I find no reference to these files in either logrotate.d or logrotate.conf nor in the system crontabs. Where is this setup? Rick, logrotate has nothing to do with the files you are interested in, as you see from logrotate.conf. Look at your /etc/cron.daily/sysklogd and /etc/cron.weekly/sysklogd scripts. They use the /usr/bin/savelog utility to rotate system logs. If log rotation is broken on your system, something must be wrong here. You might want to look at man savelog and man syslogd-listfiles. Do you use exim as MTA? Exim log rotation is handled by /etc/cron.daily/exim, also using savelog. Are your exim logs being rotated okay? If so, you'll have a working log rotation script for comparison. Cordially, Mark S. Reglewski -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- Rousseau was convinced that God, nature and man were wrong. I know that this opinion still sways many minds, but mine is not one of them. 1848 article in Journal des economistes -- Frédéric Bastiat (1801-1850) Rick Pasotto[EMAIL PROTECTED]http://www.niof.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: system logs not getting rotated
On Mon, Apr 08, 2002 at 12:04:27AM -0400, Rick Pasotto wrote: Thanks. With your help I have found what the problem *is*. Now I'd like to know *why* and *how* the problem came to be. Don't thank me too fast. See below. The cron.daily/sysklogd script passes the argument 'reload-or-restart' to /etc/init.d/sysklogd *however* that is not one of the options in the case statement. There are only a 'reload|force-reload' and a 'restart'. The cron.daily/sysklogd script was getting a usage message which went to the bit bucket. I have never manually edited *any* of these scripts. Any changes have been done via apt-get. Woody needs to be checked to verify that the problem doesn't still exist. This is very puzzling. I just flipped a potato installation to woody on Saturday, April 6. My cron.daily/sysklogd script has the same line with the 'reload-or-restart' argument, which should be bogus according to Debian Policy, section 10.3.2, which recognizes as legitimate arguments only 'start', 'stop', 'restart' and 'force-reload', or optionally, 'reload'. The line in question *looks* like a piece of pseudo-code that was inserted while the author was debating whether to restart the daemon with a restart or reload argument, but inadvertently left in the final version of the script. But my logs in woody are being rotated properly. Messages are being logged to the current /var/log/syslog file, syslog.0 syslog.1.gz have been properly created. No problem here with any logs in /var/log. If you change the line in the script to: /etc/init.d/sysklogd reload which is what it reads in the potato /etc/cron.daily/sysklogd script, does your logging get fixed? Cordially, Mark S. Reglewski -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: system logs not getting rotated
On Mon, Apr 08, 2002 at 01:19:52AM -0500, Mark S. Reglewski wrote:
I just flipped a potato installation to woody on Saturday, April 6. My
cron.daily/sysklogd script has the same line with the 'reload-or-restart'
argument, which should be bogus according to Debian Policy, section 10.3.2,
which recognizes as legitimate arguments only 'start', 'stop', 'restart' and
'force-reload', or optionally, 'reload'. The line in question *looks* like
a piece of pseudo-code that was inserted while the author was debating
whether to restart the daemon with a restart or reload argument, but
inadvertently left in the final version of the script.
D'oh. Just tested this. In potato, as root:
/etc/init.d/sysklogd reload # works
/etc/init.d/sysklogd restart # works
/etc/init.d/sysklogd reload-or-restart # fails with message:
Usage: /etc/init.d/sysklogd {start|stop|reload|restart|force-reload}
In woody *all three* commands *work*. That's right, the 'reload-or-restart'
argument works. It restarts the logging daemon without error. So Rick,
whatever is b0rking your system logging, it's not that line in
/etc/cron.daily/sysklogd.
Looks like documentation is running a little behind development here.
My chin just hit the keyboard. Time for some sleep.
Cordially,
Mark S. Reglewski
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: system logs not getting rotated
On Mon, Apr 08, 2002 at 02:06:29AM -0500, Mark S. Reglewski wrote:
On Mon, Apr 08, 2002 at 01:19:52AM -0500, Mark S. Reglewski wrote:
I just flipped a potato installation to woody on Saturday, April 6.
My cron.daily/sysklogd script has the same line with the
'reload-or-restart' argument, which should be bogus according to
Debian Policy, section 10.3.2, which recognizes as legitimate
arguments only 'start', 'stop', 'restart' and 'force-reload', or
optionally, 'reload'. The line in question *looks* like a piece of
pseudo-code that was inserted while the author was debating whether
to restart the daemon with a restart or reload argument, but
inadvertently left in the final version of the script.
D'oh. Just tested this. In potato, as root:
/etc/init.d/sysklogd reload # works
/etc/init.d/sysklogd restart # works
/etc/init.d/sysklogd reload-or-restart # fails with message: Usage:
/etc/init.d/sysklogd {start|stop|reload|restart|force-reload}
In woody *all three* commands *work*. That's right, the
'reload-or-restart' argument works. It restarts the logging daemon
without error. So Rick, whatever is b0rking your system logging, it's
not that line in /etc/cron.daily/sysklogd.
Looks like documentation is running a little behind development here.
Somehow my system has the old init.d/sysklogd script and the new
cron.daily script.
I just did 'apt-get --reinstall install sysklogd' and the init.d script
did *not* get updated. Is that behavior correct? Do I need to uninstall
and then install sysklogd?
Is this one of those script changes that produces the 'use maintainers
or keep your old' questions? If so that could be the cause of my problem
as I usually (but inconsistently) keep the old. That question seldom
gives any hint whether the new script has important changes or even if
it's the same as what's already there.
--
Try to imagine a system of labor imposed by force that is not a
violation of liberty; a transfer of wealth imposed by force that
is not a violation of property rights. If you cannot do so, then
you must agree that the law cannot organize labor and industry
without organizing injustice.
-- Frédéric Bastiat (1801-1850)
Rick Pasotto[EMAIL PROTECTED]http://www.niof.net
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: system logs not getting rotated
Well, this is interesting. I was just going to post about this. I noticed that my /var/log/messages was getting longer and longer, and still had the entries from March 17 when I did this install. I installed anacron, thinking that not having a 24-our installation might be the problem, though it has never been a problem before. I then manually ran anacron, which did restart my /var/log/messages, but this is the first time i've ever had to manually do anything about logs. hadn't checked the rest of my logs yet. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: system logs not getting rotated
On Mon, Apr 08, 2002 at 08:57:44AM -0400, Rick Pasotto wrote: Somehow my system has the old init.d/sysklogd script and the new cron.daily script. I just did 'apt-get --reinstall install sysklogd' and the init.d script did *not* get updated. Is that behavior correct? Do I need to uninstall and then install sysklogd? That *shouldn't* be necessary at all. dpkg-reconfigure package-name could be your friend here. But it only works for packages using debconf. See the short man page for more details. On my potato installation: # dpkg-reconfigure sysklogd # fails with error message: debconf: package sysklogd is not installed or does not use debconf In woody the same command works but does not ask me any configuration questions, properly so because on my woody installation there would be no differences between files on my brand new system and the ones to install. Is this one of those script changes that produces the 'use maintainers or keep your old' questions? Possibly. Don't remember from my recent potato to woody flip; there were a lot of packages for which I got these questions and I can't remember which ones, naturally. If so that could be the cause of my problem as I usually (but inconsistently) keep the old. That question seldom gives any hint whether the new script has important changes or even if it's the same as what's already there. No, Rick, I don't think that's quite correct. The question won't even come up during package configuration unless there's a diff between the old file on your system and the new maintainer's version. When this question comes up, you get a prompt to keep old, use new, or view the diffs. If you chose the last a pager screen comes up with the diffs presented for your examination, and you can decide the importance yourself. This works pretty well for short files with few diffs, but I'll admit that a big file with lots of diffs can be confusing to evaluate in the heat of the moment. And for a newcomer to Linux and Debian such as me, the significance of the changes will often not be readily apparent. Try reconfiguring your package and see whether logging gets fixed. If not, I'm running out of ideas here. Since I'm new to Debian, there weren't a lot of them to begin with. Cordially, Mark S. Reglewski -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
system logs not getting rotated
ii logrotate 3.5.9-7Log rotation utility For several weeks now my system logs have not been getting rotated. All logging is going to the .0 files. syslog, daemon.log, auth.log, etc. remain at zero length and syslog.0, daemon.log.0, auth.log.0, etc keep growing. If I reboot logging goes to the correct file until the first rotation. Is this a config problem or is there a problem with whichever program (logrotate?) does the rotating? Doesn't klogd need to be told to close the old file and open the new one? Where does that happen? I find no reference to these files in either logrotate.d or logrotate.conf nor in the system crontabs. Where is this setup? -- Every citizen who has produced or acquired a product should have the option of applying it immediately to his own use or of transferring it to whoever on the face of the earth agrees to give him in exchange the object of his desires. To deprive him of this option . . . solely to satisfy the convenience of another citizen, is to legitimize an act of plunder and to violate the law of justice. -- Frédéric Bastiat (1801-1850) Rick Pasotto[EMAIL PROTECTED]http://www.niof.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: system logs not getting rotated
On Sun, Apr 07, 2002 at 10:50:19AM -0400, Rick Pasotto wrote: ii logrotate 3.5.9-7Log rotation utility For several weeks now my system logs have not been getting rotated. All logging is going to the .0 files. syslog, daemon.log, auth.log, etc. remain at zero length and syslog.0, daemon.log.0, auth.log.0, etc keep growing. If I reboot logging goes to the correct file until the first rotation. Is this a config problem or is there a problem with whichever program (logrotate?) does the rotating? Doesn't klogd need to be told to close the old file and open the new one? Where does that happen? I find no reference to these files in either logrotate.d or logrotate.conf nor in the system crontabs. Where is this setup? Rick, logrotate has nothing to do with the files you are interested in, as you see from logrotate.conf. Look at your /etc/cron.daily/sysklogd and /etc/cron.weekly/sysklogd scripts. They use the /usr/bin/savelog utility to rotate system logs. If log rotation is broken on your system, something must be wrong here. You might want to look at man savelog and man syslogd-listfiles. Do you use exim as MTA? Exim log rotation is handled by /etc/cron.daily/exim, also using savelog. Are your exim logs being rotated okay? If so, you'll have a working log rotation script for comparison. Cordially, Mark S. Reglewski -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: system logs
On Fri, 20 Jul 2001, john gennard wrote: I've decided to have a look at /var/log which over the months has become quite large. The man page for syslog.conf and /etc/syslog.conf I basically understand, but I can't find any config file which relates to the savelog program, yet files.0 and .x.gz have been created in /var/log. OUt of the box, logrotate daily creates new logs, gzips old logs and delete logsfiles .6.gz I have little use for a great deal of logging - just the last five or six days will be enough and that for fewer facilities and priorities than are covered at present. Hopefully, I'll be able to make something of logrotate. Can someone please explain how/where savelog operates from? /etc/logrotate.conf /etc/logrotate.d/* Greetz, Sebastiaan Thanks, John. . -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
system logs
I've decided to have a look at /var/log which over the months has become quite large. The man page for syslog.conf and /etc/syslog.conf I basically understand, but I can't find any config file which relates to the savelog program, yet files.0 and .x.gz have been created in /var/log. I have little use for a great deal of logging - just the last five or six days will be enough and that for fewer facilities and priorities than are covered at present. Hopefully, I'll be able to make something of logrotate. Can someone please explain how/where savelog operates from? Thanks, John. .
Re: system logs
On Fri, Jul 20, 2001 at 06:09:32PM +0100, john gennard wrote: Can someone please explain how/where savelog operates from? grep -r savelog /etc/cron* Cheers, Joost
Re: system logs
On Fri, 20 Jul 2001, john gennard [EMAIL PROTECTED] wrote: I've decided to have a look at /var/log which over the months has become quite large. The man page for syslog.conf and /etc/syslog.conf I basically understand, but I can't find any config file which relates to the savelog program, yet files.0 and .x.gz have been created in /var/log. I have little use for a great deal of logging - just the last five or six days will be enough and that for fewer facilities and priorities than are covered at present. Hopefully, I'll be able to make something of logrotate. Can someone please explain how/where savelog operates from? For logrotate, you can set this in /etc/logrotate.conf. Unfortunately, a lot of packages still use generic maintenance scripts in /etc/cron.daily|weekly|monthly and pass command line options to savelog. To change this, you'd need to modify these scripts. For syslog, this would mean editing /etc/cron.daily/sysklogd and changing a line that looks like savelog misc switches -c 7 $LOG /dev/null to savelog misc switches -c 3 $LOG /dev/null HTH -- Philipp Lehman [EMAIL PROTECTED]
Re: system logs management
On Sun, 5 Dec 99 20:33:06 GMT John [EMAIL PROTECTED] wrote: What steps do users take to keep logs down to reasonable sizes? I have seen nothing on this aspect of management and so have been using 'rm' and then creating a new file. Look into the logrotate package. If it is possible, I would like to remove everything older than say seven days on a twice monthly basis after checking there is nothing I would like to archive for possible future reference. This is possible with logrotate. I haven't yet found a command to empty a file as opposed to removing it - does one exist? # file -- J C Lawrence Home: [EMAIL PROTECTED] --(*) Other: [EMAIL PROTECTED] --=| A man is as sane as he is dangerous to his environment |=--
system logs management
What steps do users take to keep logs down to reasonable sizes? I have seen nothing on this aspect of management and so have been using 'rm' and then creating a new file. If it is possible, I would like to remove everything older than say seven days on a twice monthly basis after checking there is nothing I would like to archive for possible future reference. I haven't yet found a command to empty a file as opposed to removing it - does one exist? Grateful for any help or pointers. Regards, John.
Re: weird crontab entries in system logs
On Sun, Jun 27, 1999 at 07:49:25PM -, Pollywog wrote: A few minutes ago, I started getting this about every five minutes. My /etc/crontab has not been changed, so I am stumped Unusual System Events =-=-=-=-=-=-=-=-=-=-= Jun 27 19:40:32 lilypad /usr/bin/crontab[7692]: (root) LIST (root) Jun 27 19:40:32 lilypad crontab[7695]: (root) REPLACE (root) Any ideas about what is going on? root listed root's crontab, then replaced it. you only need to worry if you haven't changed root's crontab at that time. -- thomas..powered.by.debian/linux. irc.:.#chatgate, #frust.ger
weird crontab entries in system logs
A few minutes ago, I started getting this about every five minutes. My /etc/crontab has not been changed, so I am stumped Unusual System Events =-=-=-=-=-=-=-=-=-=-= Jun 27 19:40:32 lilypad /usr/bin/crontab[7692]: (root) LIST (root) Jun 27 19:40:32 lilypad crontab[7695]: (root) REPLACE (root) Any ideas about what is going on? -- Andrew
