El 2/3/23 a las 17:30, Christian Göttsche escribió:
We have a VM with this issue happening right now.
ii rsyslog 8.2102.0-2+deb11u1 amd64 reliable system and
kernel logging daemon
From the rsyslog version I assume you are using logrotate version
3.18.0-2+deb11u1.
Yes.
VM is uptodate with latest security patches.
I only list syslog/user but other log files have the same issue:
# ls -l /var/log/syslog*
-rw-r----- 1 root adm 51352703 feb 27 12:56 /var/log/syslog
syslog.{1,2,3}.gz are missing
Yes, when forcing the rotation those were rotated but not the
main/current log.
-rw-r----- 1 root adm 4175 feb 17 13:45 /var/log/syslog.4.gz
-rw-r----- 1 root adm 76150956 feb 17 13:29 /var/log/syslog.5.gz
# ls -l /var/log/user*
-rw-r----- 1 root adm 436103 feb 22 17:09 /var/log/user.log
-rw-r----- 1 root adm 425984 ene 16 2185 /var/log/user.log.1
My only guesses for the timestamp are be either a gzip issue or a power outage.
Maybe some live migration crash, I can fix that if it doesn't seem
revelant to the issue.
-rw-r----- 1 root adm 5703 may 12 2022 /var/log/user.log.2.gz
-rw-r----- 1 root adm 2357 abr 19 2022 /var/log/user.log.3.gz
-rw-r----- 1 root adm 1753 abr 11 2022 /var/log/user.log.4.gz
We have forced various rotations last week. Notice there is a wrong year
in user.log.1 . I tried fixing that without result:
# ls -l /var/log/user*
-rw-r----- 1 root adm 436103 feb 22 17:09 /var/log/user.log
-rw-r----- 1 root adm 425984 ene 16 03:20 /var/log/user.log.1
-rw-r----- 1 root adm 5703 may 12 2022 /var/log/user.log.2.gz
-rw-r----- 1 root adm 2357 abr 19 2022 /var/log/user.log.3.gz
-rw-r----- 1 root adm 1753 abr 11 2022 /var/log/user.log.4.gz
# logrotate -v /etc/logrotate.d/rsyslog
reading config file /etc/logrotate.d/rsyslog
Reading state from file: /var/lib/logrotate/status
Allocating hash table for state file, size 64 entries
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Creating new state
Handling 1 logs
rotating pattern: /var/log/syslog
/var/log/mail.info
/var/log/mail.warn
/var/log/mail.err
/var/log/mail.log
/var/log/daemon.log
/var/log/kern.log
/var/log/auth.log
/var/log/user.log
/var/log/lpr.log
/var/log/cron.log
/var/log/debug
/var/log/messages
weekly (4 rotations)
empty log files are not rotated, old logs are removed
considering log /var/log/syslog
Now: 2023-02-27 13:01
Last rotated at 2023-02-27 12:47
log does not need rotating (log has been rotated at 2023-02-27 12:47,
which is less than a week ago)
So logrotate thinks the log has been rotated at 2023-02-27 12:47 due
to this date being stored in the state file
(/var/lib/logrotate/status).
Did you manually run logrotate then? Did you modify the state file manually?
Yes, we did run logrotate manually, but did not modify state file manually.
Also assuming you are using systemd, are there any errors or relevant
messages in `journalctl -u logrotate.service`?
[...]
feb 25 00:00:00 monitor-cloud systemd[1]: Starting Rotate log files...
feb 25 00:00:00 monitor-cloud systemd[1]: logrotate.service: Succeeded.
feb 25 00:00:00 monitor-cloud systemd[1]: Finished Rotate log files.
feb 26 00:00:02 monitor-cloud systemd[1]: Starting Rotate log files...
feb 26 00:00:02 monitor-cloud logrotate[2500662]: error: Compressing
program wrote following message to stderr when compressing log
/var/log/user.log.1:
feb 26 00:00:02 monitor-cloud logrotate[2500662]: gzip: stdin: warning:
file timestamp out of range for gzip format
feb 26 00:00:02 monitor-cloud logrotate[2500662]: error: failed to
compress log /var/log/user.log.1
feb 26 00:00:02 monitor-cloud systemd[1]: logrotate.service: Main
process exited, code=exited, status=1/FAILURE
feb 26 00:00:02 monitor-cloud systemd[1]: logrotate.service: Failed with
result 'exit-code'.
feb 26 00:00:02 monitor-cloud systemd[1]: Failed to start Rotate log files.
feb 27 00:00:00 monitor-cloud systemd[1]: Starting Rotate log files...
feb 27 00:00:00 monitor-cloud systemd[1]: logrotate.service: Succeeded.
feb 27 00:00:00 monitor-cloud systemd[1]: Finished Rotate log files.
[...]
It only seems anoyed with the strange date in user.log.1 , last logs a
replication of the logs of 27th.
Please also verify logrotate is acutally enabled and running
(`systemctl status logrotate.timer`).
# systemctl status logrotate.timer
● logrotate.timer - Daily rotation of log files
Loaded: loaded (/lib/systemd/system/logrotate.timer; enabled;
vendor preset: enabled)
Active: active (waiting) since Wed 2023-02-15 11:04:21 CET; 2
weeks 5 days ago
Trigger: Tue 2023-03-07 00:00:00 CET; 7h left
Triggers: ● logrotate.service
Docs: man:logrotate(8)
man:logrotate.conf(5)
Warning: journal has been rotated since unit was started, output may be
incomplete.
Thanks
EnekoLacunza
Director Técnico | Zuzendari teknikoa
Binovo IT Human Project
943 569 206 <tel:943 569 206>
elacu...@binovo.es <mailto:elacu...@binovo.es>
binovo.es <//binovo.es>
Astigarragako Bidea, 2 - 2 izda. Oficina 10-11, 20180 Oiartzun
youtube <https://www.youtube.com/user/CANALBINOVO/>
linkedin <https://www.linkedin.com/company/37269706/>
