Bug 1373562 - systemd-tmpfiles[48]: Failed to create directory or subvolume "/var/lock/opencryptoki": No such file or directory
Summary: systemd-tmpfiles[48]: Failed to create directory or subvolume "/var/lock/open...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: systemd
Version: 7.2
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: systemd-maint
QA Contact: qe-baseos-daemons
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-09-06 15:10 UTC by Jan Pazdziora
Modified: 2020-12-15 07:45 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1373833 (view as bug list)
Environment:
Last Closed: 2020-12-15 07:45:31 UTC
Target Upstream Version:


Attachments (Terms of Use)

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.


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