On Mon, 27 Feb 2023 at 13:06, Eneko Lacunza <elacu...@binovo.es> wrote:
>
> Hi,
>
> 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.
>
> 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
> -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.
> -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?
Also assuming you are using systemd, are there any errors or relevant
messages in `journalctl -u logrotate.service`?
Please also verify logrotate is acutally enabled and running
(`systemctl status logrotate.timer`).
> considering log /var/log/mail.info
> log /var/log/mail.info does not exist -- skipping
> considering log /var/log/mail.warn
> log /var/log/mail.warn does not exist -- skipping
> considering log /var/log/mail.err
> log /var/log/mail.err does not exist -- skipping
> considering log /var/log/mail.log
> log /var/log/mail.log does not exist -- skipping
> considering log /var/log/daemon.log
> 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)
> considering log /var/log/kern.log
> 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)
> considering log /var/log/auth.log
> 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)
> considering log /var/log/user.log
> 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)
> considering log /var/log/lpr.log
> log /var/log/lpr.log does not exist -- skipping
> considering log /var/log/cron.log
> log /var/log/cron.log does not exist -- skipping
> considering log /var/log/debug
> 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)
> considering log /var/log/messages
> 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)
> not running postrotate script, since no logs were rotated
>
> She thinks syslog has been rotated, but it is obvious that it wasn't :)
>
> Our (I think unchanged) /etc/logrotate.d/rsyslog:
>
>
> # cat /etc/logrotate.d/rsyslog
> /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
> {
> rotate 4
> weekly
> missingok
> notifempty
> compress
> delaycompress
> sharedscripts
> postrotate
> /usr/lib/rsyslog/rsyslog-rotate
> endscript
> }
>
>
> Thanks
>
> Eneko Lacunza
> Zuzendari teknikoa | Director técnico
> Binovo IT Human Project
>
> Tel. +34 943 569 206 | https://www.binovo.es
> Astigarragako Bidea, 2 - 2º izda. Oficina 10-11, 20180 Oiartzun
>
> https://www.youtube.com/user/CANALBINOVO
> https://www.linkedin.com/company/37269706/
>
> --
> To unsubscribe, send mail to 988652-unsubscr...@bugs.debian.org.
