/Var/log/messages is fully occupied (Problem Solving), and messages is fully occupied
We have encountered a problem before. The web service is abnormal because the log file occupies the server space.
Problem -- tomcat restarts Insufficient space for shared memory file
The solution is to delete the log file and restore it to normal.
However, after a while, I found it was full again.
To completely solve this problem, you must start with the configuration of the log file.
/Var/log/messages-contains information about the entire system, including logs recorded during system startup. Logs related to mail, cron, daemon, kern, and auth are recorded here.
Use commands
less /var/log/messages
Feb 18 04:16:59 instance-1 kernel: Cannot read proc file system: 9-Bad file descriptor.
Feb 18 04:16:59 instance-1 kernel: Cannot read proc file system: 9-Bad file descriptor.
Feb 18 04:16:59 instance-1 kernel: Cannot read proc file system: 9-Bad file descriptor.
Feb 18 04:16:59 instance-1 kernel: Cannot read proc file system: 9-Bad file descriptor.
Feb 18 04:16:59 instance-1 kernel: Cannot read proc file system: 9-Bad file descriptor.
Feb 18 04:16:59 instance-1 kernel: Cannot read proc file system: 9-Bad file descriptor.
Feb 18 04:16:59 instance-1 kernel: Cannot read proc file system: 9-Bad file descriptor.
Feb 18 04:16:59 instance-1 kernel: Cannot read proc file system: 9-Bad file descriptor.
Feb 18 04:16:59 instance-1 kernel: Cannot read proc file system: 9-Bad file descriptor.
Feb 18 04:16:59 instance-1 kernel: Cannot read proc file system: 9-Bad file descriptor.
Feb 18 04:16:59 instance-1 kernel: Cannot read proc file system: 9-Bad file descriptor.
Feb 18 04:16:59 instance-1 kernel: Cannot read proc file system: 9-Bad file descriptor.
Feb 18 04:16:59 instance-1 kernel: Cannot read proc file system: 9-Bad file descriptor.
Feb 18 04:16:59 instance-1 kernel: Cannot read proc file system: 9-Bad file descriptor.
Feb 18 04:16:59 instance-1 kernel: Cannot read proc file system: 9-Bad file descriptor.
You can see the cause of frequent errors.
If there is a serious problem, you need to solve it accordingly.
If not, you can block the information.
For example, Cannot read proc file system is caused by permission issues, but records are repeatedly recorded.
The/etc/rsyslog. conf file determines which content will be written to the corresponding log file. For example, this is the relevant content in/var/log/messages and then rsyslog. conf:
Use commands
grep "/var/log/messages" /etc/rsyslog.conf
The output is as follows:
$ Grep "/var/log/messages"/etc/rsyslog. conf
*. Info; mail. none; authpriv. none; cron. none/var/log/messages
In the above output:
*. Info indicates that all logs with the INFO mark will be recorded.
Mail. none, authpriv. none, cron. none indicate that these three error messages are not in messages.
You can also specify *. none, so that no log information is recorded.
Set it to *. none.
Use commands
vim /etc/rsyslog.conf
// Var/log/messages quickly find/var/log/messages Configuration
Change to *. none
Esc input: wq save and exit.