This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 847336 - systemd-tmpfiles fails to create directories under /var/lock (aka /run/lock)
systemd-tmpfiles fails to create directories under /var/lock (aka /run/lock)
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: systemd (Show other bugs)
17
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: systemd-maint
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-08-10 11:19 EDT by John W. Linville
Modified: 2012-08-14 13:08 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-08-14 13:08:47 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Novell 760079 None None None 2012-08-10 11:23:26 EDT

  None (edit)
Description John W. Linville 2012-08-10 11:19:29 EDT
# 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 Fri, 10 Aug 2012 10:03:08 -0400; 1h 8min ago
	    Docs: man:tmpfiles.d(5)
	 Process: 6731 ExecStart=/usr/bin/systemd-tmpfiles --create --remove (code=exited, status=0/SUCCESS)
	  CGroup: name=systemd:/system/systemd-tmpfiles-setup.service

Aug 10 10:03:08 linville-8530p.local systemd-tmpfiles[6731]: Failed to create directory /var/lock/lvm: Permission denied
Aug 10 10:03:08 linville-8530p.local systemd-tmpfiles[6731]: Failed to create directory /var/lock/ppp: Permission denied
Aug 10 10:03:08 linville-8530p.local systemd-tmpfiles[6731]: Failed to create directory /var/lock/uucp: Permission denied

'grep lock /var/log/audit/audit.log | grep -v success' gives no output, so I don't think this is an SElinux issue.

Manually running '/usr/bin/systemd-tmpfiles --create' as root creates the directories as expected.  After that, at least the uucp bits function normally.
Comment 1 Michal Schmidt 2012-08-10 11:23:56 EDT
> 'grep lock /var/log/audit/audit.log | grep -v success' gives no output, so I
> don't think this is an SElinux issue.

John,
I'm not sure this command can definitely rule SELinux out. Could you confirm that by booting with "enforcing=0" on the kernel command line?
Comment 2 John W. Linville 2012-08-10 12:10:57 EDT
OK, that does seem to let the systemd-tmpfiles service succeed.  I have no idea why the previous failures showed no trace in the audit.log...?  I thought my days of disabling SElinux were over...

So, how to fix this without disabling SElinux?
Comment 3 Michal Schmidt 2012-08-11 02:29:32 EDT
The denials may occur before auditd starts. In that case you'd find them in dmesg.

This is how the relevant files are labeled on my system. Please compare with yours:

$ ls -Zd /var /var/lock /run /run/lock /usr/bin/systemd-tmpfiles
drwxr-xr-x. root root system_u:object_r:var_run_t:s0   /run
drwxr-xr-x. root root system_u:object_r:var_lock_t:s0  /run/lock
-rwxr-xr-x. root root system_u:object_r:systemd_tmpfiles_exec_t:s0 /usr/bin/systemd-tmpfiles
drwxr-xr-x. root root system_u:object_r:var_t:s0       /var
lrwxrwxrwx. root root system_u:object_r:var_lock_t:s0  /var/lock -> ../run/lock
Comment 4 John W. Linville 2012-08-13 09:46:58 EDT
Label on /var/lock is different...

$ ls -Zd /var /var/lock /run /run/lock /usr/bin/systemd-tmpfiles 
drwxr-xr-x. root root system_u:object_r:var_run_t:s0   /run
drwxr-xr-x. root root system_u:object_r:var_lock_t:s0  /run/lock
-rwxr-xr-x. root root system_u:object_r:systemd_tmpfiles_exec_t:s0 /usr/bin/systemd-tmpfiles
drwxr-xr-x. root root system_u:object_r:var_t:s0       /var
lrwxrwxrwx. root root system_u:object_r:var_t:s0       /var/lock -> ../run/lock
Comment 5 Michal Schmidt 2012-08-13 10:01:35 EDT
Does "restorecon -v /var/lock" fix the label and the problem?
Comment 6 John W. Linville 2012-08-14 13:08:47 EDT
Michal, sorry for the late reply -- I didn't want to reboot during the day yesterday...

Yes, the relabel of that link does the trick.  I have no idea how it got mislabeled or whatnot.  Anyway, thanks.

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