Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
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.
Cause: oci-systemd-hook was running as container_t, (svirt_lxc_net_t) and should not have been.
Consequence: This caused systemctl is-active to show failures when mariadb tried to start within a container and other selinux errors.
Fix: This was corrected in oci-systemd-hook-0.1.6-1.gitfe22236.el7.x86_64.
Result: mariadb containers now start as expected.
Description of problem:
In the previous version a build script that created a mariadb docker container worked fine. The dockerfile installs mariadb.
The present version results in the container having a minimal /var/log and the /var/log/mariadb that was created by the mariadb-server rpm doesn't exist ar runtime. As a result the mariadb service fails to respond.
Version-Release number of selected component (if applicable):
oci-systemd-hook-0.1.4-9.git671c428.el7.x86_64 <-- broken
oci-systemd-hook-0.1.4-6.git337078c.el7.c86_64 <-- works
How reproducible:
always
Steps to Reproduce:
cat > Dockerfile.mariadb << EOF
FROM centos:latest
STOPSIGNAL SIGRTMIN+3
RUN yum -y install mariadb-server && yum clean all
RUN systemctl enable mariadb
VOLUME /var/lib/mysql
CMD ["/sbin/init"]
EOF
docker volume create --name localtest-mdb
docker build -f Dockerfile.mariadb -t localtest-mdb .
docker run -dt -v localtest-mdb:/var/lib/mysql --name localtest-mdb localtest-mdb
docker exec -t localtest-mdb /bin/bash -c 'for i in {1..30}; do if systemctl is-active mariadb ; then break ; else sleep 1 ; fi done;'
docker exec -t localtest-mdb mysql -e "GRANT ALL PRIVILEGES ON *.* TO 'testuser'@'%' IDENTIFIED BY 'testpassword' WITH GRANT OPTION;"
docker stop localtest-mdb
docker rm localtest-mdb
Actual results:
systemctl is-active shows failed in the container when mariadb tries to start rather than active
checking the logs it cannot find /var/log/mariadb , which was created in the docker build as a result of installing the RPM
Expected results:
On a fedora system (or older RHEL7 system, but the docker 1.12 in RHEL extras has -8 as a minimal dependency so I can't cleanly revert to the older hook) systemctl is-active shows mariadb becoming active fine.
Additional info:
Note that using the oci-systemd-hook in fedora from here shows the regression:
https://koji.fedoraproject.org/koji/buildinfo?buildID=837992
On my fedora test system (and older rhel7 installs) where I have the older hook:
[root@7bfbfd09e947 /]# ls -l /var/log/
total 32
drwxr-xr-x. 1 root root 186 Dec 14 14:59 anaconda
-rw-------. 1 root utmp 0 Dec 14 14:58 btmp
drwxr-xr-x. 1 root root 64 Feb 3 14:01 journal
-rw-r--r--. 1 root root 23944 Feb 3 13:46 lastlog
drwxr-x---. 1 mysql mysql 22 Feb 3 13:46 mariadb
-rw-------. 1 root root 0 Dec 14 14:58 tallylog
-rw-rw-r--. 1 root utmp 0 Dec 14 14:58 wtmp
-rw-------. 1 root root 4446 Feb 3 13:46 yum.log
On my fedora test system with the newer hook from koji (and this matches the current behaviour on rhel7):
[root@43f86ed6dacd /]# ls -l /var/log
total 4
-rw-------. 1 root utmp 0 Feb 3 14:02 btmp
drwxr-sr-x. 3 root systemd-journal 60 Feb 3 14:02 journal
-rw-rw-r--. 1 root utmp 384 Feb 3 14:02 wtmp
It looks like the original data isn't being copied in
Okay I just tested using rpm to force installing the older package and accepting the dependency issues for now ...
I can definitely confirm that the build&run works then and that this update is a regression that breaks anything that expects something in /var/log already to exist - such as mariadb
Aside of this, the update of oci-systemd-hook to 0.1.4-9.git671c428.el7.x86_64
leads to bug #1423502 here, while 0.1.5-1.git16f7c8a.fc25.x86_64 (as mentioned
in comment #3) indeed fixes it, thus I also would like to see the fix in RHEL
Extras.
Cross-filed case 01794554 on the Red Hat customer portal for both issues.
Btw, let me clarify this: The SELinux errors show up with both packages,
- oci-systemd-hook-0.1.4-9.git671c428.el7.x86_64
- oci-systemd-hook-0.1.5-1.git16f7c8a.fc25.x86_64
but not with the old oci-systemd-hook-0.1.4-6.git337078c.el7.c86_64. However,
yes, oci-systemd-hook-0.1.5-1.git16f7c8a.fc25.x86_64, makes MariaDB instances
working again.
As conclusion on bug #1423502 comment #5, 0.1.5-1.git16f7c8a.fc25.x86_64
for RHEL Extras is not the ultimate solution, oci-systemd-hook still needs
to be fixed instead (to avoid the behavior described in bug #1423502).
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:0949
Description of problem: In the previous version a build script that created a mariadb docker container worked fine. The dockerfile installs mariadb. The present version results in the container having a minimal /var/log and the /var/log/mariadb that was created by the mariadb-server rpm doesn't exist ar runtime. As a result the mariadb service fails to respond. Version-Release number of selected component (if applicable): oci-systemd-hook-0.1.4-9.git671c428.el7.x86_64 <-- broken oci-systemd-hook-0.1.4-6.git337078c.el7.c86_64 <-- works How reproducible: always Steps to Reproduce: cat > Dockerfile.mariadb << EOF FROM centos:latest STOPSIGNAL SIGRTMIN+3 RUN yum -y install mariadb-server && yum clean all RUN systemctl enable mariadb VOLUME /var/lib/mysql CMD ["/sbin/init"] EOF docker volume create --name localtest-mdb docker build -f Dockerfile.mariadb -t localtest-mdb . docker run -dt -v localtest-mdb:/var/lib/mysql --name localtest-mdb localtest-mdb docker exec -t localtest-mdb /bin/bash -c 'for i in {1..30}; do if systemctl is-active mariadb ; then break ; else sleep 1 ; fi done;' docker exec -t localtest-mdb mysql -e "GRANT ALL PRIVILEGES ON *.* TO 'testuser'@'%' IDENTIFIED BY 'testpassword' WITH GRANT OPTION;" docker stop localtest-mdb docker rm localtest-mdb Actual results: systemctl is-active shows failed in the container when mariadb tries to start rather than active checking the logs it cannot find /var/log/mariadb , which was created in the docker build as a result of installing the RPM Expected results: On a fedora system (or older RHEL7 system, but the docker 1.12 in RHEL extras has -8 as a minimal dependency so I can't cleanly revert to the older hook) systemctl is-active shows mariadb becoming active fine. Additional info: Note that using the oci-systemd-hook in fedora from here shows the regression: https://koji.fedoraproject.org/koji/buildinfo?buildID=837992 On my fedora test system (and older rhel7 installs) where I have the older hook: [root@7bfbfd09e947 /]# ls -l /var/log/ total 32 drwxr-xr-x. 1 root root 186 Dec 14 14:59 anaconda -rw-------. 1 root utmp 0 Dec 14 14:58 btmp drwxr-xr-x. 1 root root 64 Feb 3 14:01 journal -rw-r--r--. 1 root root 23944 Feb 3 13:46 lastlog drwxr-x---. 1 mysql mysql 22 Feb 3 13:46 mariadb -rw-------. 1 root root 0 Dec 14 14:58 tallylog -rw-rw-r--. 1 root utmp 0 Dec 14 14:58 wtmp -rw-------. 1 root root 4446 Feb 3 13:46 yum.log On my fedora test system with the newer hook from koji (and this matches the current behaviour on rhel7): [root@43f86ed6dacd /]# ls -l /var/log total 4 -rw-------. 1 root utmp 0 Feb 3 14:02 btmp drwxr-sr-x. 3 root systemd-journal 60 Feb 3 14:02 journal -rw-rw-r--. 1 root utmp 384 Feb 3 14:02 wtmp It looks like the original data isn't being copied in