Bug 1320955

I took over this bugzilla and the support case which initiated it. Just managed to nail down the configuration to reproduce.

Let's have this /etc/logrotate.d/test logrotate configuration file:

/local/rsyslog/existing
/local/rsyslog/nonexist {
    daily
    rotate 2
    create
    nodateext
    #missingok
    #sharedscripts
    postrotate
        /bin/kill -HUP `cat /var/run/syslogd.pid 2> /dev/null` 2> /dev/null || true
    endscript
}

The first file exist, the second one does not.

When logrotate is run (logrotate -vf /etc/logrotate.d/test), the files are rotated fine. Once the sharedscripts directive is uncommented, the commands output look fine at first glance, older logs are rotated, but the actual log is not; the command output misses these lines:

> fscreate context set to unconfined_u:object_r:default_t:s0
> renaming /local/rsyslog/existing to /local/rsyslog/existing.1
> creating new /local/rsyslog/existing mode = 0644 uid = 0 gid = 0
> running postrotate script

If missingok directive is uncommented as well, it works again. In the logrotate(8) manual page, the sharedscripts option is described as follows:

       sharedscripts
              Normally, prerotate and postrotate scripts are run for each log which is  rotated
              and  the absolute path to the log file is passed as first argument to the script.
              That means a single script may be run multiple times for log file  entries  which
              match  multiple  files (such as the /var/log/news/* example). If sharedscripts is
              specified, the scripts are only run once, no matter how many logs match the wild‐
              carded  pattern,  and  whole  pattern is passed to them.  However, if none of the
              logs in the pattern require rotating, the scripts will not be run at all. If  the
              scripts exit with error, the remaining actions will not be executed for any logs.
              This option overrides the nosharedscripts option and implies create option.


Seems just like misunderstanding now, or different interpretation how the rotation should work according to the options combination. The customer uses the configuration this way, and forces the rotation with -f switch. Could we have this clarified?

I agree this is a bug.  See bug #1196583 comment #3 for the cause and the fix.  The problem is that the fix caused another issue and has already been reverted upstream.

Could the missingok option be used as a workaround for the customer?

Hi Kamil,

I was far from stating this being a logrotate bug; for me it was more like unclear documentation. It looks different now, thanks for the link.

I asked our customer if he is satisfied with the workaround for now.

Is there any reason for keeping this bug private?

(In reply to Zdenek Pytela from comment #5)
> I asked our customer if he is satisfied with the workaround for now.

Thanks!  The reason I am asking is that the fix in question introduces a change in behavior, which we try to avoid in RHEL, if possible, in order not to break existing solutions of our customers.

> Is there any reason for keeping this bug private?

Not that I know of.

Currently, customer is satisfied with using the "missingok" option as a workaround, but he is interested in participation in this bugzilla and future development.

I am making this bug public.

This bug is unlikely to be fixed in RHEL-7 because the proposed fix implies a change in behavior, which could break existing installations of logrtate that rely on the current behavior.  Note that the original fix for this bug has been already reverted upstream because it caused a regression in certain configurations.

Please consider using the "missingok" directive to work around this bug.

*** Bug 1667046 has been marked as a duplicate of this bug. ***

Per comment #12 closing CANTFIX.