On my Centos 5 server, the secure file has not updated since Dec 10. This despite the fact that I run an sshd server that I access many times per day. Most peculiar is the fact that a swatch monitor that I run on the secure file catches plenty of lines. It is as if when swatch catches a line in the file, the line is removed from the file and the modification date is set back. Hard to believe. Any ideas?
Thanks, Mike.
On my Centos 5 server, the secure file has not updated since Dec 10. This despite the fact that I run an sshd server that I access many times per day. Most peculiar is the fact that a swatch monitor that I run on the secure file catches plenty of lines. It is as if when swatch catches a line in the file, the line is removed from the file and the modification date is set back. Hard to believe. Any ideas?
What is the output of "lsattr /var/log/secure"? Do you have SELinux enabled, and are there any corresponding lines in /var/log/audit/audit.log?
On Fri, 12 Dec 2008 22:43:46 -0600, Barry Brimer wrote:
On my Centos 5 server, the secure file has not updated since Dec 10. This despite the fact that I run an sshd server that I access many times per day. Most peculiar is the fact that a swatch monitor that I run on the secure file catches plenty of lines. It is as if when swatch catches a line in the file, the line is removed from the file and the modification date is set back. Hard to believe. Any ideas?
What is the output of "lsattr /var/log/secure"? Do you have SELinux enabled, and are there any corresponding lines in /var/log/audit/audit.log?
# lsattr /var/log/secure ------------- /var/log/secure
selinux is disabled
/var/log/audit/audit.log appears to have lines describing a login I did a few minutes ago, and its modification date is correct.
# ls -l /var/log/secure -rw------- 1 root root 18950 Dec 10 12:38 /var/log/secure
# date Sat Dec 13 09:42:36 EST 2008
I remain mystified.
Mike.
On my Centos 5 server, the secure file has not updated since Dec 10. This despite the fact that I run an sshd server that I access many times per day. Most peculiar is the fact that a swatch monitor that I run on the secure file catches plenty of lines. It is as if when swatch catches a line in the file, the line is removed from the file and the modification date is set back. Hard to believe. Any ideas?
What is the output of "lsattr /var/log/secure"? Do you have SELinux enabled, and are there any corresponding lines in /var/log/audit/audit.log?
# lsattr /var/log/secure ------------- /var/log/secure
selinux is disabled
/var/log/audit/audit.log appears to have lines describing a login I did a few minutes ago, and its modification date is correct.
# ls -l /var/log/secure -rw------- 1 root root 18950 Dec 10 12:38 /var/log/secure
# date Sat Dec 13 09:42:36 EST 2008
Any unexpected syslog configuration? Does a touch update the timestamp?
On Sat, 13 Dec 2008 11:33:06 -0600, Barry Brimer wrote:
On my Centos 5 server, the secure file has not updated since Dec 10. This despite the fact that I run an sshd server that I access many times per day. Most peculiar is the fact that a swatch monitor that I run on the secure file catches plenty of lines. It is as if when swatch catches a line in the file, the line is removed from the file and the modification date is set back. Hard to believe. Any ideas?
What is the output of "lsattr /var/log/secure"? Do you have SELinux enabled, and are there any corresponding lines in /var/log/audit/audit.log?
# lsattr /var/log/secure ------------- /var/log/secure
selinux is disabled
/var/log/audit/audit.log appears to have lines describing a login I did a few minutes ago, and its modification date is correct.
# ls -l /var/log/secure -rw------- 1 root root 18950 Dec 10 12:38 /var/log/secure
# date Sat Dec 13 09:42:36 EST 2008
Any unexpected syslog configuration? Does a touch update the timestamp?
in syslog.conf:
# added by MDB local0.* /var/log/httpd/cgi_log local1.* /var/log/net_que local2.* /var/log/sock_mon kern.=debug /var/log/ipt_log
I also have added a number of things to logrotate.
These things have been working well for years, although only a few months on "Centos.
"touch /var/log/secure" updated the timestamp as expected.
I note that early tomorrow morning the logrotate occurs. I wonder what will happen.
Mike.
Further examination shows numerous log lines that were detected on Dec 12 by swatch using tail on the secure file but do not presently appear in the secure file. However, they do appear in the messages file.
Mike.
On Sun, 14 Dec 2008 02:25:17 +0000, Mike -- EMAIL IGNORED wrote:
Further examination shows numerous log lines that were detected on Dec 12 by swatch using tail on the secure file but do not presently appear in the secure file. However, they do appear in the messages file.
Mike.
Here are some tentative observations:
If I do a vi on the secure file and write it from vi, it stops recording. If I do a "/var/init.d/syslog restart", the secure file starts recording.
I still have no idea how swatch continues to function after the syslog stops recording.
Mike.
Hi,
On Sun, Dec 14, 2008 at 15:26, Mike -- EMAIL IGNORED m_d_berger_1900@yahoo.com wrote:
If I do a vi on the secure file and write it from vi, it stops recording.
Yes, that's the expected behaviour, because "vi" will actually write a new file and rename it to /var/log/secure, so syslog will no longer be writing to that file.
The file syslog is now writing to is not accessible on the filesystem (unless you created a hardlink to it before), but other processes that had it open before you saved it with "vi" will continue using the old one.
If I do a "/var/init.d/syslog restart", the secure file starts recording.
Yes, because syslog will open the new file again, by it's name, now it's the file "vi" wrote. Actually, when you stop syslog (and all other processes that had the old file open) it will be effectively deleted, but not before that.
I still have no idea how swatch continues to function after the syslog stops recording.
I'm not familiar with swatch, so I cannot say how it interacts with files that are written/renamed as you described with "vi".
If it's a "daemon" that is running on background all the time, chances are it will keep the file open (although not necessarily), so in this case it will "see" the new entries from syslog. If it's run from cron at fixed intervals, it will open the file every time it runs, so chances are if you rewrite the file with "vi" it will no longer see the new entries from syslog.
In any case, opening a logfile with "vi" is a bad idea, you should use a more appropriate tool such as "less", or if you really want to use "vi" commands, use "vi -R" or "view" for read-only mode.
HTH, Filipe
On Sun, 14 Dec 2008 20:47:36 -0500, Filipe Brandenburger wrote:
Hi,
On Sun, Dec 14, 2008 at 15:26, Mike -- EMAIL IGNORED m_d_berger_1900@yahoo.com wrote:
If I do a vi on the secure file and write it from vi, it stops recording.
Yes, that's the expected behaviour, because "vi" will actually write a new file and rename it to /var/log/secure, so syslog will no longer be writing to that file.
The file syslog is now writing to is not accessible on the filesystem (unless you created a hardlink to it before), but other processes that had it open before you saved it with "vi" will continue using the old one.
If I do a "/var/init.d/syslog restart", the secure file starts recording.
Yes, because syslog will open the new file again, by it's name, now it's the file "vi" wrote. Actually, when you stop syslog (and all other processes that had the old file open) it will be effectively deleted, but not before that.
I still have no idea how swatch continues to function after the syslog stops recording.
I'm not familiar with swatch, so I cannot say how it interacts with files that are written/renamed as you described with "vi".
If it's a "daemon" that is running on background all the time, chances are it will keep the file open (although not necessarily), so in this case it will "see" the new entries from syslog. If it's run from cron at fixed intervals, it will open the file every time it runs, so chances are if you rewrite the file with "vi" it will no longer see the new entries from syslog.
In any case, opening a logfile with "vi" is a bad idea, you should use a more appropriate tool such as "less", or if you really want to use "vi" commands, use "vi -R" or "view" for read-only mode.
HTH, Filipe
Very interesting analysis. swatch uses tail -f, or something that mimics it to watch the file. I would then guess that as per your explanation, swatch contilues to watch the "old file".
Mike.
Hi,
On Sun, Dec 14, 2008 at 21:25, Mike -- EMAIL IGNORED m_d_berger_1900@yahoo.com wrote:
Very interesting analysis. swatch uses tail -f, or something that mimics it to watch the file. I would then guess that as per your explanation, swatch contilues to watch the "old file".
Yes, actually using "tail -f" in a terminal while using "vi" to rewrite the logfile in another terminal you can check that yourself.
You can also use "ls -li" to show the "inode number" of the file, you will see that after saving the file with "vi" the inode will change, which will mean that it's a new file.
Filipe
-
Barry Brimer -
Filipe Brandenburger -
Mike -- EMAIL IGNORED