I used Nano to access the secure log since I had found Fail2ban is no longer working. I didn't make any changes but simply exited the file. Now logging to that file has stopped at the exact time I accessed the file.

I've rebooted the server twice since then but still the logging has stopped on 16:30 yesterday.

Why has this happened?

  • 1
    Perhaps you have inadvertently changed the permissions (or SELinux context?) of the file. What does ls -lhZ /var/log/secure and sestatus say. I would also recommend using less or something similarly read-only when viewing logs. nano is kinda dangerous in my (admittedly dated) experience (nano -w is much safer when looking at config files especially). – Cameron Kerr May 23 '17 at 10:29
  • @CameronKerr Permissiong are -rw------- root root ? and sestatus says disabled. Thanks! – user2924019 May 23 '17 at 10:35
  • Odd that even a reboot didn't resolve it. How about forcing a log rotation using logrotate -f /etc/logrotate.conf (check using the manual page that -f will do a force though). If you do something like a login, then you should see that new entries in the file. You might also look for other reasons it might fail (eg. do df -h /var/log/ or df -hi /var/log/ show using at 100%). Failing that, you might check that your syslog (rsyslogd / syslogd) is still running. What version of ContOS are you using? – Cameron Kerr May 23 '17 at 10:46
  • I used your logrotate command and the secure file is now empty. I'm getting 1000+ failed login attempts every hour but that file has remained blank. CentOS 7.2. 18% space used also. The server did stop working yesterday and apache errors said out of memory, but the memory and disk weren't being used much. The restart fixed that anyway. – user2924019 May 23 '17 at 14:30
  • Turn your attention to the configuration of your logging. What is in /etc/syslogd.conf or /etc/rsyslogd.conf? Also check the configuration of /etc/ssh/sshd_config and your fail2ban and show what the logging configuration is for that. What does ls -lh /dev/log show? – Cameron Kerr May 23 '17 at 19:22

This happens when you re-create or mess with /var/log/secure file. This will break file permissions, especially if SELinux is enabled.

Do the following:

Make sure /var/log/secure is owned by root:root

$ sudo chown root:root /var/log/secure

Make sure the permission is set to 600

$ sudo chmod 600 /var/log/secure

If SELinux is enabled, you can temporarily disable while troubleshooting your issue

$ sudo setenforce 0

If you decide to keep SELinux enabled, make sure the file has the following context:

$ ls -lZh /var/log/secure

To manipulate SELinux on the fly (copy context from an existing known working):

$ sudo chcon --reference /var/log/dmesg /var/log/secure

To manipulate SELinux context permanently, use the semanage command instead.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.