My understand is that such behaviour should be resolved by bz#1272236 but I still see it.

(In reply to Douglas Schilling Landgraf from comment #1)
> My understand is that such behaviour should be resolved by bz#1272236 but I
> still see it.

The fix for bug #1272236 only changes the cron script to pass -s /var/lib/logrotate/logrotate.status to logrotate:

+++ b/examples/logrotate.cron
@@ -1,6 +1,6 @@
 #!/bin/sh

-/usr/sbin/logrotate /etc/logrotate.conf
+/usr/sbin/logrotate -s /var/lib/logrotate/logrotate.status /etc/logrotate.conf
 EXITVALUE=$?
 if [ $EXITVALUE != 0 ]; then
     /usr/bin/logger -t logrotate "ALERT exited abnormally with [$EXITVALUE]"

According to logrotate(8) man page, /var/lib/logrotate.status is still the default state file.

I am not the author of this downstream-only change, so it is difficult for me to explain the reasoning behind, but it works the same way in Fedora for quite some time now.

Hi Kamil,

(In reply to Kamil Dudka from comment #3)
> (In reply to Douglas Schilling Landgraf from comment #1)
> > My understand is that such behaviour should be resolved by bz#1272236 but I
> > still see it.
> 
> The fix for bug #1272236 only changes the cron script to pass -s
> /var/lib/logrotate/logrotate.status to logrotate:
> 
> +++ b/examples/logrotate.cron
> @@ -1,6 +1,6 @@
>  #!/bin/sh
> 
> -/usr/sbin/logrotate /etc/logrotate.conf
> +/usr/sbin/logrotate -s /var/lib/logrotate/logrotate.status
> /etc/logrotate.conf
>  EXITVALUE=$?
>  if [ $EXITVALUE != 0 ]; then
>      /usr/bin/logger -t logrotate "ALERT exited abnormally with [$EXITVALUE]"
> 
> According to logrotate(8) man page, /var/lib/logrotate.status is still the
> default state file.

Sure, I have a proposal patch for logrotate that will change it [1].

> 
> I am not the author of this downstream-only change, so it is difficult for
> me to explain the reasoning behind, but it works the same way in Fedora for
> quite some time now.

Instead of downstream-only proposal, I have sent a proposal upstream that should solve these RO scenarios. Please let me know if you have any thoughts/suggestions about it.

[1] https://github.com/logrotate/logrotate/commit/c76dcf905dfdc129ebab578caa5beee7ab2e8fa3

Thanks!

More data:

# cat /etc/redhat-release 
Red Hat Enterprise Virtualization Hypervisor release 7.3 (20161004.0.el7ev)

# rpm -qa | grep -i logrotate
logrotate-3.8.6-12.el7.x86_64

# cat /var/log/cron 
Oct 18 02:47:40 localhost crond[1871]: (CRON) INFO (Syslog will be used instead of sendmail.)
Oct 18 02:47:40 localhost crond[1871]: (CRON) INFO (RANDOM_DELAY will be scaled with factor 54% if used.)
Oct 18 02:47:41 localhost crond[1871]: (CRON) INFO (running with inotify support)
Oct 18 02:48:01 localhost CROND[2391]: (root) CMD (python < /usr/share/rhn/virtualization/poller.py)
Oct 18 02:50:01 localhost CROND[11511]: (root) CMD (python < /usr/share/rhn/virtualization/poller.py)
Oct 18 02:50:01 localhost CROND[11512]: (root) CMD (/usr/lib64/sa/sa1 1 1)
Oct 18 02:50:01 localhost CROND[11513]: (root) CMD (/usr/sbin/logrotate /etc/logrotate.conf)
Oct 18 02:50:01 localhost CROND[11505]: (root) CMDOUT (error: error creating state file /var/lib/logrotate.status: Read-only file system)
Oct 18 02:51:20 localhost crond[1871]: (CRON) INFO (Shutting down)
Oct 18 02:51:57 localhost crond[2021]: (CRON) INFO (Syslog will be used instead of sendmail.)
Oct 18 02:51:57 localhost crond[2021]: (CRON) INFO (RANDOM_DELAY will be scaled with factor 26% if used.)
Oct 18 02:51:58 localhost crond[2021]: (CRON) INFO (running with inotify support)
Oct 18 02:52:01 localhost CROND[4969]: (root) CMD (python < /usr/share/rhn/virtualization/poller.py)
Oct 18 02:54:01 localhost CROND[17518]: (root) CMD (python < /usr/share/rhn/virtualization/poller.py)

Looks weird.  Are you using the cron script installed by logrotate?

Please try the following:
# rpm -V logrotate
# grep status /etc/cron.daily/logrotate

From a fresh install:

# cat /etc/redhat-release 
Red Hat Enterprise Virtualization Hypervisor release 7.3 (20161004.0.el7ev)

# rpm -qa | grep -i logrotate
logrotate-3.8.6-12.el7.x86_64

# rpm -V logrotate
missing   c /etc/cron.daily/logrotate
missing   c /var/lib/logrotate/logrotate.status

You might wondering why the /etc/cron.daily is not there, I have found in our legacy code the below statement from 2000-2001. However, keep in mind that we have text user interface that allow users to change logrotate settings to their need.

"""
recipe/common-post.ks
<snip>
# Remove the default logrotate daily cron job
# since we run it every 10 minutes instead.
rm -f /etc/cron.daily/logrotate
</snip>
"""

We already discussed it by email but let's make the record here as well:
In our case, there are services like vdsm and ovirt-node that adds in cron a logrotate call:

#etc> grep -rni logrotate *
<snip>
cron.d/ovirt-logrotate:2:*/10 * * * * root /usr/sbin/logrotate
/etc/logrotate.conf

Specially this one:
=========================
cron.hourly/vdsm-logrotate:3:/usr/sbin/logrotate /etc/vdsm/logrotate/vdsm
</snip>


# cat /etc/vdsm/logrotate/vdsm 
/var/log/vdsm/*.log {
    rotate 100
    missingok
    size 15M
    compress
    compresscmd /usr/bin/xz
    uncompresscmd /usr/bin/unxz
    compressext .xz
}
/var/log/core/*.dump {
    rotate 1
    missingok
    size 0
    compress
    compresscmd /usr/bin/xz
    uncompresscmd /usr/bin/unxz
    compressext .xz
    su root root
}

This case is very bad, because the logging rotate of vdsm is not working and might create a full disk scenario as I can demonstrate here:

1) Create 65M log file:
# cd /var/log/vdsm
# dd if=/dev/zero of=vdsm.log bs=64M count=1 
1+0 records in
1+0 records out

2) Let's mimic the vdsm logrotate call from cron:

# logrotate /etc/vdsm/logrotate/vdsm 
error: error creating state file /var/lib/logrotate.status: Read-only file system

3) Still 65M, which is wrong as vdsm should rotate when log is 15M:
# du -sh *
4.0K	backup
4.0K	connectivity.log
4.0K	mom.log
12K	supervdsm.log
4.0K	upgrade.log
65M	vdsm.log

4) Remounting the FS as RW, the logrotate works and reduce the size:
# mount -o remount,rw /
# logrotate /etc/vdsm/logrotate/vdsm 
# du -sh *
4.0K	backup
4.0K	connectivity.log
4.0K	mom.log
12K	supervdsm.log
4.0K	upgrade.log
4.0K	vdsm.log
12K	vdsm.log.1.xz

Thanks for the clarification!  This is definitely not a regression in logrotate.  The fix for bug #1272236 is just less ambitious than you would like it to be.  I am fine with changing the default state file in RHEL-7 if the change gets merged in upstream and Fedora.

(In reply to Kamil Dudka from comment #8)
> Thanks for the clarification!  This is definitely not a regression in
> logrotate.  The fix for bug #1272236 is just less ambitious than you would
> like it to be.  I am fine with changing the default state file in RHEL-7 if
> the change gets merged in upstream and Fedora.

Sure, I have noticed new comments in my pull request. I am working on an updated patch/pull request.

Thanks!

upstream commits:
https://github.com/logrotate/logrotate/commit/72827266
https://github.com/logrotate/logrotate/commit/0ea240b9

fixed in logrotate-3.10.0-4.fc26 for now:
http://pkgs.fedoraproject.org/cgit/rpms/logrotate.git/commit/?id=3799546e

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2017:1889