Project

General

Profile

Actions

Bug #4433

closed

Log rotation problems due to bad post-rotate script

Added by Alex Tkachenko about 10 years ago. Updated almost 9 years ago.

Status:
Rejected
Priority:
2
Category:
System integration
Target version:
Severity:
UX impact:
User visibility:
Effort required:
Priority:
Name check:
Fix check:
Regression:

Description

First off - thank you very much for the New Year post card which I received just recently - this is so sweet of you!
Sorry if this is inappropriate place - I just do not know where else to write to all of you :)

I have noticed a couple of issues related to the subject.

First off, for rsyslog-based log files (I am speaking of RHEL, don't know about the others) new files have been created but relevant applications evidently continued to write into the old files. This is caused by improper postrotate script. Currently it uses

/etc/init.d/httpd reload > /dev/null

However, at least on my CentOS 6.5 box the reload option for that script merely exits with status code 3. There is a force-reload option, which essentially does a full daemon restart. The rsyslog documentation shipped with the stock package discusses the problem at hand, and the bottom line is that the full restart is quite expensive and is not recommended for log rotation purposes. It is suggested to use HUP signal, so the postrotate block should do something like

killall -HUP rsyslogd

I just have checked the stock rsyslog packages on CentOS5 - there are two versions, rsyslog (v3) and rslyslog5. The latter would have exactly the same issues that the one on CentOS6; rsyslog v3 actually has the reload option to the init script, but a closer look reveals that it does signalling too, just in a more sophisticated fashion, so the suggested above killall would also do.

Another problem is secondary to the previous - if the new files are created but never written to, the "notifemtpy" option sort of guarantees that proper rotation will never be attempted again - this will lead the system to run out of space, eventually. I would suggest dropping that option.

And the last issue is with non-compliant-reports.log - very similar to the above - the new file created but not switched to - but it is not an rsyslog-driven and there is no postrotate action. Which application (if any) and how needs to be prompted to switch to the new file? Also, the file /var/log/rudder/core/rudder-webapp.log may be the subject to the same issue, but it is written only once a day, and I do not want to restart the program, as restarting it would switch to the new file for sure, but I would lose the ability to confirm that the switch actually happened today.


Related issues 5 (1 open4 closed)

Related to Rudder - Bug #3868: The files written by java in /var/log/rudder/core/*.log are still empty after a logrotateRejected2013-08-22Actions
Related to Rudder - Bug #6381: File /var/log/rudder/{compliance/non-compliant-reports.log, core/rudder-webapp.log} are not correctly rotatedReleasedNicolas CHARLES2015-03-11Actions
Related to Rudder - Bug #3916: Jetty should compress the files rotated (/var/log/rudder/webapp/*.log)ReleasedNicolas CHARLES2013-09-09Actions
Related to Rudder - User story #6384: Clean log rotation & compression letting Java aloneNew2015-03-11Actions
Is duplicate of Rudder - Bug #6526: Log rotation of reports and slapd is not correctly functionnal on redhat, as the server continues to write to the move fileReleasedBenoît PECCATTE2015-05-13Actions
Actions #1

Updated by Matthieu CERDA about 10 years ago

  • Project changed from Rudder to 34
  • Status changed from New to 8
  • Assignee set to Matthieu CERDA
  • Priority changed from N/A to 2
  • Target version set to 2.6.11
Actions #2

Updated by Matthieu CERDA about 10 years ago

Hey Alex,

First of all, no prob for New Year post card !!! Come by our IRC channel one day if you want to tell the whole team :) (#rudder@freenode)

I'm taking care of this (when the FOSDEM/cfgmgmtcamp will be over that is) !

Actions #3

Updated by Vincent MEMBRÉ about 10 years ago

  • Target version changed from 2.6.11 to 2.6.12
Actions #4

Updated by Vincent MEMBRÉ about 10 years ago

  • Target version changed from 2.6.12 to 2.6.13
Actions #5

Updated by Vincent MEMBRÉ almost 10 years ago

  • Target version changed from 2.6.13 to 2.6.14
Actions #6

Updated by Jonathan CLARKE almost 10 years ago

  • Target version changed from 2.6.14 to 2.6.16
Actions #7

Updated by Jonathan CLARKE almost 10 years ago

  • Target version changed from 2.6.16 to 2.6.17
Actions #8

Updated by Nicolas PERRON over 9 years ago

  • Target version changed from 2.6.17 to 2.6.18
Actions #9

Updated by Matthieu CERDA over 9 years ago

  • Target version changed from 2.6.18 to 2.6.19
Actions #10

Updated by Vincent MEMBRÉ over 9 years ago

  • Target version changed from 2.6.19 to 2.6.20
Actions #11

Updated by François ARMAND about 9 years ago

  • Target version changed from 2.6.20 to 2.10.10
Actions #12

Updated by Vincent MEMBRÉ about 9 years ago

  • Target version changed from 2.10.10 to 2.10.11
Actions #13

Updated by Vincent MEMBRÉ about 9 years ago

  • Target version changed from 2.10.11 to 2.10.12
Actions #14

Updated by Benoît PECCATTE about 9 years ago

  • Project changed from 34 to Rudder
  • Category set to Packaging
Actions #15

Updated by Vincent MEMBRÉ about 9 years ago

  • Target version changed from 2.10.12 to 2.10.13
Actions #16

Updated by François ARMAND about 9 years ago

  • Subject changed from Log rotation problems to Log rotation problems due to bad post-rotate script
  • Reproduced set to No

Some update with that old ticket:

We make a recap of the situation for thing not managed by logrotate in #6384. For now, everything in that case should be correctly rotated and compressed.

We still have to see for the rsyslog problem.

Actions #17

Updated by François ARMAND about 9 years ago

  • Category changed from Packaging to System integration
  • Assignee changed from Matthieu CERDA to Benoît PECCATTE

Benoit,

Could you check if it is still the case ?

Actions #18

Updated by Benoît PECCATTE almost 9 years ago

  • Status changed from 8 to New
Actions #19

Updated by Vincent MEMBRÉ almost 9 years ago

  • Target version changed from 2.10.13 to 2.10.14
Actions #20

Updated by Benoît PECCATTE almost 9 years ago

This has been duplicated by #6526 but the patch has been sent to it, so i'm rejecting this one as a duplicate.
But it's fixed now.

Actions #21

Updated by Benoît PECCATTE almost 9 years ago

  • Is duplicate of Bug #6526: Log rotation of reports and slapd is not correctly functionnal on redhat, as the server continues to write to the move file added
Actions #22

Updated by Benoît PECCATTE almost 9 years ago

  • Status changed from New to Rejected
Actions

Also available in: Atom PDF