Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 57456 - Improve & clearify 'include' directive
Improve & clearify 'include' directive
Product: Red Hat Raw Hide
Classification: Retired
Component: logrotate (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Elliot Lee
Aaron Brown
: FutureFeature
Depends On:
  Show dependency treegraph
Reported: 2001-12-12 18:16 EST by Enrico Scholz
Modified: 2007-04-18 12:38 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-12-18 21:18:35 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Lets read 'include' the files of a directory in alphabetic order. (5.13 KB, patch)
2001-12-18 21:08 EST, Enrico Scholz
no flags Details | Diff
summarized dmalloc result (2.91 KB, text/plain)
2001-12-18 21:17 EST, Enrico Scholz
no flags Details

  None (edit)
Description Enrico Scholz 2001-12-12 18:16:25 EST
Since /etc/logrotate.conf will be overwritten occasionally (see
bug #14081), it is impossible to modify this file without losing
reliability. To make global adaptations possible (e.g. another
olddir directory, another rotation cycle) without changing this
file I suggest:

1. when including an entire directory (e.g.'include /etc/logrotate.d')
   sort the filelist as it is done by 'ls'. Then a file
   /etc/logrotate.d/0options can be created which contains global

   Modules like the initscripts or vixie-cron are using a similar


2. Add something like 'include /etc/logrotate-site.conf' before the
   'include /etc/logrotate.d' in /etc/logrotate.conf. Then this
   file should be marked as %config(noreplace) and the user can
   make modifications there. Packages like a2ps or lynx are using a
   similar approach.

   When using this method, options in global sections should be handled
   either as errors (e.g.

      ----- /etc/logrotate.d/samba
     | olddir /var/log/.old/samba
     | /var/log/samba/*.log { ... }

   would be erroneously) or the changed options should be reset when
   leaving the file.

In any case, the mechanism how entire directories are read (sorted at
1. and random at 2.) should be mentioned in the manpage explicitly.
Comment 1 Elliot Lee 2001-12-18 19:09:55 EST
These days rpm seems to generate .rpmnew files instead of .rpmsave's, so I'm not
really sure that your suggestions make sense anymore. If .rpmsave's are still a
problem, we would probably need to discuss that ancient bug 14081 (I think there
is a communications gap there as to why .rpmsave's make sense) before
implementing this solution.
Comment 2 Enrico Scholz 2001-12-18 19:28:24 EST
I don't speak about rpmsave or rpmnew files (and no, because '%config' and not
'%config(noreplace)' is used for /etc/logrotate.conf, this file will be renamed
to ...rpmsave and replaced by the RH logrotate.conf).

I speak about the order in which the files are read. Currently this order is
determined by the inode-number which is very difficulty to influence.

E.g. consider a file /etc/logrotate.d/0options where local configurations are
placed into. When will this file be read? Before /etc/logrotate.d/psacct? This
randomness makes it very difficultly to make local adaptations.
Comment 3 Elliot Lee 2001-12-18 19:50:58 EST
My point was that the only reason you are worried about the sort order of the
directory is because you don't understand the whole reason behind doing .rpmsave
, and while I'll gladly take a patch, I'm not going to spend time coding on a
way for you to avoid working with rpm.

If you would like to discuss the reasons behind .rpmsave's, their advantages and
disadvantages, or perhaps using noreplace on logrotate.conf, I'd be glad to have
a conversation via e-mail with you.
Comment 4 Enrico Scholz 2001-12-18 20:24:34 EST
I am not happy with your decision to keep /etc/logrotate.conf marked as %config
only, but I accept it because you may have good reasons to replace it when
changes are necessarily.

The real flaw is the undetermined behavior of the 'include' statement. I will
give a full example:

 --- /etc/logrotate.conf --  ## default file from logrotate-package
| ...
| include "/etc/logrotate.d"
| ...

 --- /etc/logrotate.d/0options --  ## local configuration
| olddir /var/log/.old

 --- /etc/logrotate.d/rpm ---   ## from rpm-package
| /var/log/rpmpkgs {
|     weekly
|     notifempty
|     missingok
| }

logrotate accepts both the 0options and rpm file and handles them while
executing 'logrotate /etc/logrotate.conf'. But it is completely unclear where
the rotated /var/log/rpmpkgs file will be placed.

When '0options' has a lower inode-number, it will be moved into /var/log/.old,
else into /var/log. This is ambiguous and the logrotate-documentation says
nothing about this case. An expected behavior would be a sorted executing of the
included files or prohibition of global options in included files.

I will see if/when I can provide a patch...
Comment 5 Enrico Scholz 2001-12-18 21:08:03 EST
Created attachment 40987 [details]
Lets read 'include' the files of a directory in alphabetic order.
Comment 6 Enrico Scholz 2001-12-18 21:16:01 EST
Patch should provide behavior as described in 1) of the initial report.

BTW: While checking for resource-leaks introduced by my patch I have found other
ones. I will attach the dmalloc result... (locations are refering to
logrotate-3.6-1 + my patch).
Comment 7 Enrico Scholz 2001-12-18 21:17:39 EST
Created attachment 40988 [details]
summarized dmalloc result
Comment 8 Elliot Lee 2001-12-31 13:18:18 EST
Thanks, patch committed to CVS.

The memory leaks are not a huge concern, since logrotate is not a long-running
program. But again, patches welcome. :)

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