rsyslog Ausfall nach rotate - auth.log fail2ban.log leer

ClusterX · Dec 6, 2020

Debian 10
Kernel: 5.4.78-1-pve

Nach dem Upgrade von Proxmox 5.4-15 auf 6.3, habe ich festgestellt das keine /var/run/rsyslogd.pid mehr vorhanden ist, der Service wird aber als aktiv angezeigt:

Code:

systemctl status rsyslog
● rsyslog.service - System Logging Service
   Loaded: loaded (/lib/systemd/system/rsyslog.service; enabled; vendor preset: enabled)
   Active: active (running) since Sun 2020-12-06 15:34:43 CET; 15min ago
     Docs: man:rsyslogd(8)
           https://www.rsyslog.com/doc/
Main PID: 24088 (rsyslogd)
    Tasks: 4 (limit: 4915)
   Memory: 968.0K
   CGroup: /system.slice/rsyslog.service
           └─24088 /usr/sbin/rsyslogd -n -iNONE

Dec 06 15:34:43 host00 systemd[1]: Starting System Logging Service...
Dec 06 15:34:43 host00 systemd[1]: Started System Logging Service.
Dec 06 15:34:43 host00 rsyslogd[24088]: imuxsock: Acquired UNIX socket '/run/systemd/journal/syslog' (fd 3) from systemd.  [v8.1901.0
Dec 06 15:34:43 host00 rsyslogd[24088]:  [origin software="rsyslogd" swVersion="8.1901.0" x-pid="24088" x-info="https://www.rsyslog.c

auch der cron service startet verspätet, also etwa 5 Minuten nach einem reboot ist die /var/run/crond.pid vorhanden.

Habe heute nun ein Kernel Update durchgeführt und mir die Startscripte einmal genauer angeschaut, da sind vermutlich noch nach den ganzen Upgrades alte init Startscripte vorhanden:

Code:

/etc/rsyslog.conf
/etc/rsyslog.d
/etc/default/rsyslog
/etc/init.d/rsyslog
/etc/logcheck/ignore.d.server/rsyslog
/etc/logrotate.d/rsyslog
/etc/monit/conf-available/rsyslog
/etc/rc0.d/K01rsyslog
/etc/rc1.d/K01rsyslog
/etc/rc2.d/S01rsyslog
/etc/rc3.d/S01rsyslog
/etc/rc4.d/S01rsyslog
/etc/rc5.d/S01rsyslog
/etc/rc6.d/K01rsyslog
/etc/rsyslog.d/postfix.conf
/etc/systemd/system/multi-user.target.wants/rsyslog.service

cron
/etc/rc2.d/S01cron
/etc/rc3.d/S01cron
/etc/rc4.d/S01cron
/etc/rc5.d/S01cron

Vor dem heutigen Upgrade war die auth.log leer seit gestern Nacht (0:00 nach dem rotieren), Fail2Ban hat auch nichts mehr geloggt ... nach dem heutigen Upgrade & reboot musste ich rsyslog & fail2ban nochmal manuell restarten:
systemctl restart rsyslog
systemctl restart fail2ban

danach hat fail2ban auch wieder funktioniert und blockiert wieder ....

kann es sein dass es hier Konflikte gibt und müssen diese /etc/rcX.d/K01rsyslog Starter noch gelöscht werden bzw. was genau ist zu tun?

### edit ###
hier noch weitere Infos:

Code:

sudo 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 Sun 2020-12-06 15:14:20 CET; 1h 29min ago
Trigger: Mon 2020-12-07 00:00:00 CET; 7h left
Docs: man:logrotate(8)
man:logrotate.conf(5)

Code:

systemctl status logrotate  
● logrotate.service - Rotate log files
Loaded: loaded (/lib/systemd/system/logrotate.service; static; vendor preset: enabled)
Active: inactive (dead)
Docs: man:logrotate(8)
man:logrotate.conf(5)

Code:

cat /etc/logrotate.d/rsyslog

/var/log/syslog
{
rotate 7
daily
missingok
notifempty
delaycompress
compress
postrotate
/usr/lib/rsyslog/rsyslog-rotate
endscript
}

der Zeitpunkt mit der 7 Tage Rotation kommt dann mit letzter Nacht 0:00 hin, ab der Rotation wurde zumindest die auth.log nicht mehr geschrieben, bis heute nach dem Upgrade und reboot.

Wie kann das Problem gelöst werden?

oguz · Dec 7, 2020

hi,
stimmt die zeit auf der maschine?

ClusterX said:
Nach dem Upgrade von Proxmox 5.4-15 auf 6.3, hab

hast du waehrend des updates den pve5to6 script benutzt? [0]

[0]: https://pve.proxmox.com/wiki/Upgrade_from_5.x_to_6.0#In-place_upgrade

ClusterX · Dec 7, 2020

oguz said:
hi,
stimmt die zeit auf der maschine?

hast du waehrend des updates den pve5to6 script benutzt? [0]

[0]: https://pve.proxmox.com/wiki/Upgrade_from_5.x_to_6.0#In-place_upgrade

ja beim Upgrade check mit pve5to6 war alles OK auch das Upgrade ist ohne Probleme durchgelaufen, war alles OK bis Samstag 0:00 Uhr, ab da wurde die auth.log nicht mehr geschrieben nach der Rotation (Log Dateirechte haben gestimmt) - date ist auch alles OK (Mon 07 Dec 2020 01:43:39 PM CET). Momentan wird wieder alles geloggt ...
so wie ich das sehe ist logrotate ja wg. der Umstellung auf logrotate.timer permanent inaktiv (dead) oder muss der Service noch zusätzlich aktiviert werden?

Code:

systemctl status logrotate 
● logrotate.service - Rotate log files
Loaded: loaded (/lib/systemd/system/logrotate.service; static; vendor preset: enabled)
Active: inactive (dead)
Docs: man:logrotate(8)
man:logrotate.conf(5)

Könnte eventl. ein Debian Bug sein aufgrund der Umstellung auf logrotate.timer?
Bin mal gespannt wie es am nächsten Sonntag aussieht ...

oguz · Dec 7, 2020

ClusterX said:
/etc/monit/conf-available/rsyslog

was steht denn hier drin?

ClusterX · Dec 7, 2020

oguz said:
was steht denn hier drin?

#cat /etc/monit/conf-available/rsyslog

Code:

 check process rsyslogd with pidfile /var/run/rsyslogd.pid
   group system
group rsyslogd
start program = "/etc/init.d/rsyslog start"
stop program = "/etc/init.d/rsyslog stop"
if 5 restarts with 5 cycles then timeout
depend on rsyslogd_bin
depend on rsyslogd_rc
depend on rsyslog_file

check file rsyslogd_bin with path /usr/sbin/rsyslogd
group rsyslogd
include /etc/monit/templates/rootbin

check file rsyslogd_rc with path "/etc/init.d/rsyslog"
group rsyslogd
include /etc/monit/templates/rootbin

check file rsyslog_file with path /var/log/syslog
group rsyslogd
   # Note: activate the immark plugin for rsyslog if
   # your system is too low on events.
if timestamp > 65 minutes then alert
if failed permission 640 then unmonitor
if failed uid root then unmonitor
if failed gid adm then unmonitor

oguz · Dec 7, 2020

kannst du monit disablen und schauen ob es geht?

ClusterX · Dec 7, 2020

oguz said:
kannst du monit disablen und schauen ob es geht?

Danke, hab alles auskommentiert und rsyslog neu gestartet, das logging läuft derweil - die /var/run/rsyslogd.pid existiert weiterhin nicht ... ist das so OK für Debian 10? Ist wohl nur ein socket:

Code:

systemctl status rsyslog   
● rsyslog.service - System Logging Service
Loaded: loaded (/lib/systemd/system/rsyslog.service; enabled; vendor preset: enabled)
Active: active (running) since Mon 2020-12-07 14:22:08 CET; 5min ago
Docs: man:rsyslogd(8)
https://www.rsyslog.com/doc/
Main PID: 3999 (rsyslogd)
Tasks: 4 (limit: 4915)
Memory: 880.0K
CGroup: /system.slice/rsyslog.service
└─3999 /usr/sbin/rsyslogd -n -iNONE

Dec 07 14:22:08 host00 systemd[1]: Starting System Logging Service...
Dec 07 14:22:08 host00 rsyslogd[3999]: imuxsock: Acquired UNIX socket '/run/systemd/journal/syslog' (fd 3) from systemd. [v8.1901.0]
Dec 07 14:22:08 host00 rsyslogd[3999]: [origin software="rsyslogd" swVersion="8.1901.0" x-pid="3999" x-info="https://www.rsyslog.com
Dec 07 14:22:08 host00 systemd[1]: Started System Logging Service.
[code]

oguz · Dec 7, 2020

ja, ist normal (habe das gleiche bei mir)

ClusterX · Dec 7, 2020

in monit habe ich jetzt nur noch folgende services ohne restart Bedingung, nur pid checks & disks:

Code:

# cron
check process cron with pidfile /var/run/crond.pid
   group services

# fail2ban
check process fail2ban with pidfile /var/run/fail2ban/fail2ban.pid
   group services

# diskspace
check device rootfs with path /dev/mapper/vg0-data
     if space usage > 80% 5 times within 15 cycles
     then alert

kann das bleiben oder sollte ich monit besser ganz weglassen?

oguz · Dec 7, 2020

/var/run/crond.pid und /var/run/fail2ban/fail2ban.pid existieren also sollte es schon ok sein.

wenn es nach weiteren problemen kommt dann kannst du vielleicht den monit ganz weglassen.

ClusterX · Dec 7, 2020

Danke Oguz, ich behalte es dann mal im Auge bis nächsten Montag!

Search

Search

rsyslog Ausfall nach rotate - auth.log fail2ban.log leer

ClusterX

Member

oguz

Proxmox Retired Staff

ClusterX

Member

oguz

Proxmox Retired Staff

ClusterX

Member

oguz

Proxmox Retired Staff

ClusterX

Member

oguz

Proxmox Retired Staff

ClusterX

Member

oguz

Proxmox Retired Staff

ClusterX

Member