Bug 982276 - /etc/tmpfiles.d doesn't get processed inside systemd-nspawn
Summary: /etc/tmpfiles.d doesn't get processed inside systemd-nspawn
Keywords:
Status: CLOSED DUPLICATE of bug 975864
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: 19
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: systemd-maint
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-07-08 14:43 UTC by Nathaniel McCallum
Modified: 2013-07-10 13:45 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-07-10 13:45:02 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Nathaniel McCallum 2013-07-08 14:43:42 UTC
1. Install a container: http://fedoraproject.org/wiki/Features/SystemdLightweightContainers

2. Install freeipa inside the container: yum install freeipa-server

3. Run ipa install: ipa-install

4. Note various problems starting 389ds.

5. Note that the lock directories for 389ds are missing.

6. Note that there is no problem with /etc/tmpfiles.d/dirsrv-${INSTANCE}.conf.

Comment 1 Nathaniel McCallum 2013-07-08 14:56:01 UTC
-bash-4.2# systemctl status systemd-tmpfiles-setup.service 
systemd-tmpfiles-setup.service - Recreate Volatile Files and Directories
   Loaded: loaded (/usr/lib/systemd/system/systemd-tmpfiles-setup.service; static)
   Active: active (exited) since Mon 2013-07-08 10:13:56 EDT; 37min ago
     Docs: man:tmpfiles.d(5)
           man:systemd-tmpfiles(8)
  Process: 20 ExecStart=/usr/bin/systemd-tmpfiles --create --remove (code=exited, status=0/SUCCESS)

Jul 08 10:13:56 freeipa.mccallum.lan systemd[1]: Starting Recreate Volatile Files and Directories...
Jul 08 10:13:56 freeipa.mccallum.lan systemd[1]: Started Recreate Volatile Files and Directories.


-bash-4.2# cat /etc/tmpfiles.d/dirsrv-MCCALLUM-LAN.conf 
d /var/run/dirsrv 0770 dirsrv dirsrv
d /var/lock/dirsrv 0770 dirsrv dirsrv
d /var/lock/dirsrv/slapd-MCCALLUM-LAN 0770 dirsrv dirsrv


-bash-4.2# ls -lh /var/lock/
total 0
drwxrwxr-x 2 root lock 40 Jul  8 10:13 lockdev
drwxr-xr-x 4 root root 80 Jul  8 10:13 pki
drwxr-xr-x 2 root root 40 Jul  8 10:13 subsys

Comment 2 Nathaniel McCallum 2013-07-08 14:57:19 UTC
So apparently the .conf file is being run, but the directories aren't being created.

Running the exact same command manually after login properly creates the directories...

Comment 3 Michal Schmidt 2013-07-08 15:02:58 UTC
(In reply to Nathaniel McCallum from comment #1)
> -bash-4.2# cat /etc/tmpfiles.d/dirsrv-MCCALLUM-LAN.conf 
> d /var/run/dirsrv 0770 dirsrv dirsrv
> d /var/lock/dirsrv 0770 dirsrv dirsrv
> d /var/lock/dirsrv/slapd-MCCALLUM-LAN 0770 dirsrv dirsrv

One thing that comes to mind is that on a normal Fedora system, /var/run and /var/lock are symlinks to ../run/lock and ../run, respectively. Please verify this is the case in your container.

Comment 4 Michal Schmidt 2013-07-08 15:03:49 UTC
Sorry. The other way around. In /var:
lock -> ../run/lock
run -> ../run

Comment 5 Nathaniel McCallum 2013-07-08 16:00:28 UTC
# ls -lhd /var/lock /var/run
lrwxrwxrwx  1 root root   11 Jul  8 09:10 /var/lock -> ../run/lock
drwxr-xr-x 14 root root 4.0K Jul  8 11:34 /var/run

That is on a completely fresh install using the official instructions.

Comment 6 Lennart Poettering 2013-07-08 22:23:39 UTC
Sounds like an iteration of:

https://bugzilla.redhat.com/show_bug.cgi?id=919374

Nathaniel, is that the same issue? Did you encounter the issue when creating an OS tree with the packages where that fix to filesytem.rpm is applied?

Comment 7 Kay Sievers 2013-07-08 22:58:48 UTC
Yum creates that directory before anything else, we cannot fix that
with the (fixed) filesystem.rpm alone:
  https://bugzilla.redhat.com/show_bug.cgi?id=975864

dnf might be fixed already:
  https://bugzilla.redhat.com/show_bug.cgi?id=975858

Comment 8 Nathaniel McCallum 2013-07-10 13:45:02 UTC
I am almost certain that this bug is a duplicate of https://bugzilla.redhat.com/show_bug.cgi?id=975864

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


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