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.
DescriptionJan Pazdziora (Red Hat)
2016-09-06 15:10:54 UTC
Description of problem:
Sometimes when running container with opencryptoki installed and with --tmpfs /run, the systemd-tmpfiles-setup.service fails with
Sep 06 10:59:20 fe26baa90bc3 systemd[1]: Starting Create Volatile Files and Directories...
Sep 06 10:59:20 fe26baa90bc3 systemd-tmpfiles[48]: Failed to create directory or subvolume "/var/lock/opencryptoki": No such file or directory
Sep 06 10:59:20 fe26baa90bc3 systemd-tmpfiles[48]: Failed to create directory or subvolume "/var/lock/opencryptoki/swtok": No such file or directory
Sep 06 10:59:20 fe26baa90bc3 systemd-tmpfiles[48]: Failed to create directory or subvolume "/var/lock/opencryptoki/tpm": No such file or directory
Sep 06 10:59:20 fe26baa90bc3 systemd[1]: systemd-tmpfiles-setup.service: main process exited, code=exited, status=1/FAILURE
Sep 06 10:59:20 fe26baa90bc3 systemd[1]: Failed to start Create Volatile Files and Directories.
Version-Release number of selected component (if applicable):
systemd-219-19.el7_2.12.x86_64
How reproducible:
Not 100 % deterministic but happening very often.
Steps to Reproduce:
1. Have Dockerfile
FROM rhel7
RUN yum install --disablerepo='*' --enablerepo=rhel-7-server-rpms -y opencryptoki
LABEL RUN 'docker run --rm -ti -e container=docker -v /sys/fs/cgroup:/sys/fs/cgroup:ro --tmpfs /run --tmpfs /tmp ${NAME} /usr/sbin/init'
2. Build container image with
docker build -t systemd-tmpfiles-opencryptoki .
3. Run
while true ; do docker run --name systemd-tmpfiles -d -e container=docker -v /sys/fs/cgroup:/sys/fs/cgroup:ro --tmpfs /run --tmpfs /tmp systemd-tmpfiles-opencryptoki /usr/sbin/init ; sleep 2 ; docker exec -ti systemd-tmpfiles systemctl status systemd-tmpfiles-setup.service -l ; docker rm -f systemd-tmpfiles ; done
Actual results:
Sooner or later the systemd-tmpfiles service will be shown failed.
Expected results:
No failure.
Additional info:
/usr/lib/tmpfiles.d/legacy.conf defines
d /run/lock 0755 root root -
L /var/lock - - - - ../run/lock
and /usr/lib/tmpfiles.d/opencryptoki.conf defines
D /var/lock/opencryptoki 0770 root pkcs11 -
D /var/lock/opencryptoki/icsf 0770 root pkcs11 -
D /var/lock/opencryptoki/swtok 0770 root pkcs11 -
D /var/lock/opencryptoki/tpm 0770 root pkcs11 -
and man tmpfiles.d(5) says that configuration files are lexicographically ordered and that prefixes are processed first, so I'd expect /run/lock to exist when /var/lock/opencryptoki is being created.
Granted, /run/lock is not prefix of /var/lock/opencryptoki but at least legacy.conf should be processed before opencryptoki.conf.
I suspect that fixing this will take us some time, so meanwhile let's clone this bug to opencryptoki. We should try to get rid of legacy stuff at least in our packages.
Comment 4RHEL Program Management
2020-12-15 07:45:31 UTC
After evaluating this issue, there are no plans to address it further or fix it in an upcoming release. Therefore, it is being closed. If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.
Description of problem: Sometimes when running container with opencryptoki installed and with --tmpfs /run, the systemd-tmpfiles-setup.service fails with Sep 06 10:59:20 fe26baa90bc3 systemd[1]: Starting Create Volatile Files and Directories... Sep 06 10:59:20 fe26baa90bc3 systemd-tmpfiles[48]: Failed to create directory or subvolume "/var/lock/opencryptoki": No such file or directory Sep 06 10:59:20 fe26baa90bc3 systemd-tmpfiles[48]: Failed to create directory or subvolume "/var/lock/opencryptoki/swtok": No such file or directory Sep 06 10:59:20 fe26baa90bc3 systemd-tmpfiles[48]: Failed to create directory or subvolume "/var/lock/opencryptoki/tpm": No such file or directory Sep 06 10:59:20 fe26baa90bc3 systemd[1]: systemd-tmpfiles-setup.service: main process exited, code=exited, status=1/FAILURE Sep 06 10:59:20 fe26baa90bc3 systemd[1]: Failed to start Create Volatile Files and Directories. Version-Release number of selected component (if applicable): systemd-219-19.el7_2.12.x86_64 How reproducible: Not 100 % deterministic but happening very often. Steps to Reproduce: 1. Have Dockerfile FROM rhel7 RUN yum install --disablerepo='*' --enablerepo=rhel-7-server-rpms -y opencryptoki LABEL RUN 'docker run --rm -ti -e container=docker -v /sys/fs/cgroup:/sys/fs/cgroup:ro --tmpfs /run --tmpfs /tmp ${NAME} /usr/sbin/init' 2. Build container image with docker build -t systemd-tmpfiles-opencryptoki . 3. Run while true ; do docker run --name systemd-tmpfiles -d -e container=docker -v /sys/fs/cgroup:/sys/fs/cgroup:ro --tmpfs /run --tmpfs /tmp systemd-tmpfiles-opencryptoki /usr/sbin/init ; sleep 2 ; docker exec -ti systemd-tmpfiles systemctl status systemd-tmpfiles-setup.service -l ; docker rm -f systemd-tmpfiles ; done Actual results: Sooner or later the systemd-tmpfiles service will be shown failed. Expected results: No failure. Additional info: /usr/lib/tmpfiles.d/legacy.conf defines d /run/lock 0755 root root - L /var/lock - - - - ../run/lock and /usr/lib/tmpfiles.d/opencryptoki.conf defines D /var/lock/opencryptoki 0770 root pkcs11 - D /var/lock/opencryptoki/icsf 0770 root pkcs11 - D /var/lock/opencryptoki/swtok 0770 root pkcs11 - D /var/lock/opencryptoki/tpm 0770 root pkcs11 - and man tmpfiles.d(5) says that configuration files are lexicographically ordered and that prefixes are processed first, so I'd expect /run/lock to exist when /var/lock/opencryptoki is being created. Granted, /run/lock is not prefix of /var/lock/opencryptoki but at least legacy.conf should be processed before opencryptoki.conf.