Bug 1446391 - logrotate for mongodb creates additional files
Summary: logrotate for mongodb creates additional files
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Fedora
Classification: Fedora
Component: mongodb
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Marek Skalický
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-04-27 19:47 UTC by Pradeep Kilambi
Modified: 2017-05-09 08:33 UTC (History)
10 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2017-05-09 08:33:57 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
Patch to fix logrotate file (631 bytes, text/plain)
2017-04-27 19:48 UTC, Pradeep Kilambi
no flags Details
Fix for logrotate (631 bytes, text/plain)
2017-04-27 20:01 UTC, Pradeep Kilambi
no flags Details

Description Pradeep Kilambi 2017-04-27 19:47:57 UTC
Description of problem:
logrotate for mongodb logrotate file creates an additional file

How reproducible:
always

Steps to Reproduce:
1. Run "logrotate -f /etc/logrotate.conf"

Actual results:
mongodb logrotate creates two files.

Expected results:
The logrotate should only create one file.

Additional info:

ls looks as follows:

-rw-r--r--.  1 mongodb mongodb    0 Jan 11 18:35 mongod.log
-rw-r--r--.  1 mongodb mongodb 1168 Dec 20 03:06 mongod.log-20151220.gz
-rw-r--r--.  1 mongodb mongodb  493 Dec 27 03:40 mongod.log-20151227.gz
-rw-r--r--.  1 mongodb mongodb  493 Jan  3 13:37 mongod.log-20160103.gz
-rw-r--r--.  1 mongodb mongodb 2843 Jan 11 18:35 mongod.log-20160111
-rw-r--r--.  1 mongodb mongodb    0 Dec 20 03:06 mongod.log.2015-12-20T02-06-01
-rw-r--r--.  1 mongodb mongodb    0 Dec 27 03:40 mongod.log.2015-12-27T02-40-01
-rw-r--r--.  1 mongodb mongodb    0 Jan  3 13:37 mongod.log.2016-01-03T12-37-01

This is due to mongodb having its own logrotate on SIGUSR1 signal.
As we have "copyontruncate" set, the USR1 is not needed.

So we could just remove the postrotate action from the logrotate:

# cat /etc/logrotate.d/mongodb 
/var/log/mongodb/*.log {
       weekly
       rotate 10
       copytruncate
       delaycompress
       compress
       notifempty
       missingok
==>       postrotate
==>          /bin/kill -USR1 `cat /var/run/mongodb/mongod.pid 2>/dev/null` 2> /dev/null|| true
==>       endscript
}

See also https://docs.mongodb.com/v2.6/reference/command/logRotate/ for some additional information.

Comment 1 Pradeep Kilambi 2017-04-27 19:48:41 UTC
Created attachment 1274781 [details]
Patch to fix logrotate file

Comment 2 Pradeep Kilambi 2017-04-27 19:51:53 UTC
Can you please review the attached patch and merge if you're ok with it.Thanks!

Comment 4 Pradeep Kilambi 2017-04-27 20:01:13 UTC
Created attachment 1274785 [details]
Fix for logrotate

Comment 6 Marek Skalický 2017-04-28 05:36:47 UTC
Hi,

upstream introduced fix for this in MongoDB 3.0 - https://docs.mongodb.com/v3.0/tutorial/rotate-log-files/#log-rotation-with-logrotate-reopen (this option improve working with logrotate utility and solves this problem).

All versions of Fedora uses MongoDB 3.0+, so they should not have this problem. Have you tested this bug in Fedora?


For MongoDB 2.6 in EPEL7 I hope it is fixed too. See the bug #1410238 and the fix http://pkgs.fedoraproject.org/cgit/rpms/mongodb.git/commit/?h=epel7&id=ebbb1e6f631804bbb922fc53c513b9bc48c3b2fa

I don't suggest fixing this by removing '/bin/kill -USR1' to mongod process. Without this mongodb does not know, that rotation was done. A default behavior is that mongodb adds "start up" information to new log file after rotation (to know more information about which mongod produced new log, configuration,...). First it is upstream behavior. Also it seems useful to me.

Pradeep, is this bug reproducible in Fedora?

Comment 8 Marek Skalický 2017-05-09 08:33:57 UTC
This issue is already fixed in fedora - for MongoDB 3.0+ by upsteam change, for MongoDB 2.6 in EPEL7 in above mentioned bug #1410238

So closing this bug. Feel free to reopen.


Note You need to log in before you can comment on or make changes to this bug.