Bug 1373562

Summary: systemd-tmpfiles[48]: Failed to create directory or subvolume "/var/lock/opencryptoki": No such file or directory
Product: Red Hat Enterprise Linux 7 Reporter: Jan Pazdziora <jpazdziora>
Component: systemdAssignee: systemd-maint
Status: CLOSED WONTFIX QA Contact: qe-baseos-daemons
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 7.2CC: systemd-maint-list
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 1373833 (view as bug list) Environment:
Last Closed: 2020-12-15 07:45:31 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Jan Pazdziora 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.

Comment 1 Lukáš Nykrýn 2016-09-07 08:46:04 UTC
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 4 RHEL 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.