Operations grimoire/Logs: Difference between revisions
No edit summary |
|||
| (One intermediate revision by the same user not shown) | |||
| Line 1: | Line 1: | ||
Logrotate is a utility in Linux that manages log file rotation, archiving, and deletion automatically to prevent logs from consuming all disk space. The configuration is usually placed in /etc/logrotate.conf for global settings and in /etc/logrotate.d/ for application-specific log policies | |||
Logrotate is a utility in Linux that manages log file rotation, archiving, and deletion automatically to prevent logs from consuming all disk space. The configuration is usually placed in /etc/logrotate.conf for global settings and in /etc/logrotate.d/ for application-specific log policies | |||
To configure logrotate for a specific service, create a file in /etc/logrotate.d/, for example /etc/logrotate.d/nginx, and add a block describing how the log files should be rotated: | To configure logrotate for a specific service, create a file in /etc/logrotate.d/, for example /etc/logrotate.d/nginx, and add a block describing how the log files should be rotated: | ||
| Line 18: | Line 15: | ||
} | } | ||
Logs are generally located in /var/log directory, but can also be in specialized systems (e.g. Docker) | |||
How to create a logrotate configuration (Linux) | |||
Logrotate is a utility in Linux that manages log file rotation, archiving, and deletion automatically to prevent logs from consuming all disk space. The configuration is usually placed in /etc/logrotate.conf for global settings and in /etc/logrotate.d/ for application-specific log policies. | |||
To configure logrotate for a specific service, create a file in /etc/logrotate.d/, for example /etc/logrotate.d/nginx, and add a block describing how the log files should be rotated: | |||
To | |||
/var/log/nginx/*.log { | /var/log/nginx/*.log { | ||
| Line 41: | Line 34: | ||
endscript | endscript | ||
} | } | ||
For | |||
To create a configuration for newsyslog under FreeBSD, you need to add or modify a line in the main file /etc/newsyslog.confor in an auxiliary configuration file, often specific to a service. | |||
newsyslog is a utility on FreeBSD that manages log rotation, compression, and removal for system and application logs. Configuration is performed by adding or editing lines in /etc/newsyslog.conf or a custom file (often included with .conf extension in /etc/newsyslog.conf.d/ | |||
/var/log/www/*/*.log root:web 640 90 * @T00 JC /var/run/nginx.pid 30 | |||
If you're manipulating patterns with wildcards (like *), don't forget the option G. Otherwise, the system might create a literal file named ` *` or not process the files as expected. | |||
If you’re using wildcards, the G flag must be set to properly match multiple files. Without it, newsyslog may create a file literally named * or fail to manage the files as intended. | |||
For a complete explanation of each field, see the manual:https://man.freebsd.org/cgi/man.cgi?newsyslog.conf(5) | |||
When the "G" flag is omitted with newsyslog on FreeBSD and a pattern containing wildcards is used, as *in the path, several problems can occur: | |||
Nothing happens: The rotation does not take place at all, because newsyslog does not understand that it must process all files matching the pattern (for example /var/log/nginx/*.log), and tries to open a file named literally with the asterisk. | |||
Worse, creation of a “*” file : If we also use option C (auto creation), newsyslog can create a file called “*” in the target directory… this is of course unintended and can cause problems in log processing. | |||
To avoid this, you should ALWAYS add the flag Gwhen specifying a pattern in the “log filename” field. The flag Ginstructs newsyslog to read the path as a glob shell pattern, and therefore to process all matching files in a batch — exactly as expected. | |||
See the official documentation newsyslog.conf(5) for the definition and precautions relating to the "G" flag. | |||
After a log file is rotated (renamed and a new one created), many applications will not automatically start writing to the new file—they keep writing to the now-renamed (old) log file. To solve this, the application must be notified to reopen its log files. This is commonly done by sending a specific signal (not a kill -9, which forcefully terminates the process, but a well-defined signal the application knows how to handle, like SIGHUP or SIGUSR1). | |||
Similarly, with newsyslog (FreeBSD), it's possible to specify the path to the application's PID file and choose the appropriate signal so the daemon can close and reopen its log files after rotation. | |||
This mechanism ensures the application immediately starts writing to the new log file, guaranteeing complete and organized log capture | |||
Latest revision as of 13:01, 22 November 2025
Logrotate is a utility in Linux that manages log file rotation, archiving, and deletion automatically to prevent logs from consuming all disk space. The configuration is usually placed in /etc/logrotate.conf for global settings and in /etc/logrotate.d/ for application-specific log policies
To configure logrotate for a specific service, create a file in /etc/logrotate.d/, for example /etc/logrotate.d/nginx, and add a block describing how the log files should be rotated:
/var/log/nginx/*.log {
daily
rotate 7
compress
missingok
notifempty
create 640 root adm
postrotate
systemctl reload nginx > /dev/null
endscript
}
Logs are generally located in /var/log directory, but can also be in specialized systems (e.g. Docker)
How to create a logrotate configuration (Linux) Logrotate is a utility in Linux that manages log file rotation, archiving, and deletion automatically to prevent logs from consuming all disk space. The configuration is usually placed in /etc/logrotate.conf for global settings and in /etc/logrotate.d/ for application-specific log policies.
To configure logrotate for a specific service, create a file in /etc/logrotate.d/, for example /etc/logrotate.d/nginx, and add a block describing how the log files should be rotated:
/var/log/nginx/*.log {
daily
rotate 7
compress
missingok
notifempty
create 640 root adm
postrotate
systemctl reload nginx > /dev/null
endscript
}
To create a configuration for newsyslog under FreeBSD, you need to add or modify a line in the main file /etc/newsyslog.confor in an auxiliary configuration file, often specific to a service.
newsyslog is a utility on FreeBSD that manages log rotation, compression, and removal for system and application logs. Configuration is performed by adding or editing lines in /etc/newsyslog.conf or a custom file (often included with .conf extension in /etc/newsyslog.conf.d/
/var/log/www/*/*.log root:web 640 90 * @T00 JC /var/run/nginx.pid 30
If you're manipulating patterns with wildcards (like *), don't forget the option G. Otherwise, the system might create a literal file named ` *` or not process the files as expected.
If you’re using wildcards, the G flag must be set to properly match multiple files. Without it, newsyslog may create a file literally named * or fail to manage the files as intended.
For a complete explanation of each field, see the manual:https://man.freebsd.org/cgi/man.cgi?newsyslog.conf(5)
When the "G" flag is omitted with newsyslog on FreeBSD and a pattern containing wildcards is used, as *in the path, several problems can occur:
Nothing happens: The rotation does not take place at all, because newsyslog does not understand that it must process all files matching the pattern (for example /var/log/nginx/*.log), and tries to open a file named literally with the asterisk.
Worse, creation of a “*” file : If we also use option C (auto creation), newsyslog can create a file called “*” in the target directory… this is of course unintended and can cause problems in log processing.
To avoid this, you should ALWAYS add the flag Gwhen specifying a pattern in the “log filename” field. The flag Ginstructs newsyslog to read the path as a glob shell pattern, and therefore to process all matching files in a batch — exactly as expected.
See the official documentation newsyslog.conf(5) for the definition and precautions relating to the "G" flag.
After a log file is rotated (renamed and a new one created), many applications will not automatically start writing to the new file—they keep writing to the now-renamed (old) log file. To solve this, the application must be notified to reopen its log files. This is commonly done by sending a specific signal (not a kill -9, which forcefully terminates the process, but a well-defined signal the application knows how to handle, like SIGHUP or SIGUSR1).
Similarly, with newsyslog (FreeBSD), it's possible to specify the path to the application's PID file and choose the appropriate signal so the daemon can close and reopen its log files after rotation.
This mechanism ensures the application immediately starts writing to the new log file, guaranteeing complete and organized log capture
