RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 2021216 - logrotate fails without error if unresolved sym link is encountered when run inside a container, as in OpenStack 16.1
Summary: logrotate fails without error if unresolved sym link is encountered when run ...
Keywords:
Status: CLOSED DUPLICATE of bug 1723265
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: logrotate
Version: 8.2
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Kamil Dudka
QA Contact: qe-baseos-daemons
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-11-08 15:24 UTC by Matthew Secaur
Modified: 2022-03-16 06:11 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-11-08 16:22:33 UTC
Type: Bug
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker RHELPLAN-101994 0 None None None 2021-11-08 15:52:02 UTC

Description Matthew Secaur 2021-11-08 15:24:50 UTC
Description of problem:
With logrotate 3.14.0 running in a container on the controllers, such as logrotate_crond in OpenStack 16.1, if a path in the logrotate configuration is a symbolic link that is not resolvable inside the container, logrotate exits normally but without finding any logs to rotate, even though there are potentially dozens of logs matching rotation criteria. 
This results in logs not being rotated and taking up many GB of space.

Version-Release number of selected component (if applicable):
logrotate 3.14.0

How reproducible:
Option #1 - How customers might encounter the issue
Install OpenStack 13 (logrotate 3.8.6). On the OpenStack controllers, the log directory /var/log/containers/swift will be a link to /var/log/swift. Inside the logrotate_crond container, that path does not resolve, but logrotate still works normally. But, after upgrading to OpenStack 16.1 (or presumably 16.2) which uses logrotate 3.14.0, logs will no longer be rotated.

Option #2 - To manually reproduce the issue
Install OpenStack 16.1 (logrotate 3.14.0). On the controllers, move the logs in the directory /var/log/containers/swift/* to /var/log/swift, then remove the /var/log/containers/swift directory and make it a symbolic link (ln -s /var/log/swift /var/log/containers/swift). The logs will stop rotating and running logrotate manually inside the logrotate_crond container will exit normally saying that there are no logs to process, even with -v, -d, and/or -f.

Steps to Reproduce:
Option #1 - How customers might encounter the issue
1. Install OpenStack 13.
2. Note that the controllers use a symbolic link from /var/log/containers/swift to /var/log/swift.
3. Note that there is a bind mount in the logrotate_crond container for /var/log/containers:/var/log/containers, but not a mount for /var/log (i.e. /var/log/swift exists on the host OS but not inside the container)
4. Upgrade to OpenStack 16.1.
5. Note that the symbolic link for /var/log/containers/swift -> /var/log/swift still exists.
6. Note that logrotate will stop rotating logs. Furthermore, '/usr/sbin/logrotate -v -f -s /var/lib/logrotate/logrotate-crond.status /etc/logrotate-crond.conf' run inside the container will exit with the message "No logs found. Rotation not needed." even though the logs require rotation.

Option #2 - To manually reproduce the issue
1. Install OpenStack 16.1.6
2. Note that the controllers use a directory for /var/log/containers/swift, not a link.
3. Note that logrotate run from within the container is working normally.
4. On the host OS (NOT inside the container), replace /var/log/containers/swift with a symbolic link to /var/log/swift
5. Run '/usr/sbin/logrotate -v -f -s /var/lib/logrotate/logrotate-crond.status /etc/logrotate-crond.conf' inside the logrotate_crond container. 
6. Note the message "No logs found. Rotation not needed." even though logs do require rotation.

Actual results:
The logrotate command inside the container exits with the message "No logs found. Rotation not needed." even though logs do require rotation.

Expected results:
Either logrotate needs to function even with an unresolvable symbolic link -OR- logrotate needs to give an error indicating that it can not proceed due to an unresolvable symbolic link. 

Additional info:
Option #1 above has been seen in a customer environment, but Option #2 will more readily allow for recreation of the problem, even though that isn't how customers will encounter the problem.

Comment 1 Kamil Dudka 2021-11-08 16:02:45 UTC
I believe this bug was fixed in logrotate-3.15.1:

    https://github.com/logrotate/logrotate/commit/4297f01103915f4ee356d37bdb35e8c41bbbdb28

We can backport the patch from upstream.

Comment 2 Kamil Dudka 2021-11-08 16:14:42 UTC
Actually, this should have already been backported via bug #1723265.  Which build of logrotate are you using exactly?

$ rpm -q logrotate

Comment 3 Matthew Secaur 2021-11-08 16:16:43 UTC
[root@pnq-controller02 ~]# podman exec -it logrotate_crond logrotate --version
logrotate 3.14.0

    Default mail command:       /bin/mail
    Default compress command:   /bin/gzip
    Default uncompress command: /bin/gunzip
    Default compress extension: .gz
    Default state file path:    /var/lib/logrotate/logrotate.status
    ACL support:                yes
    SELinux support:            yes

Comment 4 Matthew Secaur 2021-11-08 16:17:11 UTC
[root@pnq-controller02 ~]# podman exec -it logrotate_crond rpm -q -a | grep logrotate
logrotate-3.14.0-3.el8.x86_64

Comment 5 Kamil Dudka 2021-11-08 16:22:33 UTC
Thanks for the quick reply!  That pretty much explains it.  Please update to logrotate-3.14.0-4.el8 and it will work as expected.

*** This bug has been marked as a duplicate of bug 1723265 ***


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