Bug 36993 - ConditionPathExists not working for units/sys-kernel-security.automount
Summary: ConditionPathExists not working for units/sys-kernel-security.automount
Status: RESOLVED NOTABUG
Alias: None
Product: systemd
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
Hardware: Other Linux (All)
: medium normal
Assignee: Lennart Poettering
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-05-09 01:46 UTC by Daniel Drake
Modified: 2011-05-14 15:39 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
my kernel config (74.29 KB, text/plain)
2011-05-09 14:00 UTC, Daniel Drake
Details
strace log (13.43 KB, text/plain)
2011-05-14 15:09 UTC, Daniel Drake
Details

Description Daniel Drake 2011-05-09 01:46:41 UTC
Testing Fedora rawhide spin on OLPC XO-1.5 (custom kernel), includes systemd v26 from Fedora.

I don't have whatever kernel option is needed to make the /sys/kernel/security directory exist.

Looking at units/sys-kernel-security.automount, I guess this line means it should only try and mount /sys/kernel/security if the directory already exists:

     ConditionPathExists=/sys/kernel/security

This doesn't seem to be working, as early during boot I get these errors:

[    8.282950] Failed to initialize automounter: No such file or directory
[    8.290826] <29>systemd[1]: Unit sys-kernel-security.automount entered failed state.

i.e. systemd has tried to mount it anyway (confirmed with printf debugging)

I assume there is a bug somewhere in the handling of ConditionPathExists.
Comment 1 Kay Sievers 2011-05-09 03:42:50 UTC
I can not reproduce this. *seems* to work all fine here. Please check your setup again.

  # ls -l /sys/kernel/security
  ls: cannot access /sys/kernel/security: No such file or directory

  # systemctl status sys-kernel-security.automount
  sys-kernel-security.automount - Security File System Automount Point
  Loaded: loaded (/lib/systemd/system/sys-kernel-security.automount)
  Active: inactive (dead)
          start condition failed at Mon, 09 May 2011 12:37:09 +0200; 3min 14s ago
  Where: /sys/kernel/security
Comment 2 Lennart Poettering 2011-05-09 11:09:42 UTC
I think this is a misunderstanding mostly. You seem to have enabled the feature that makes /sys/kernel/security but have not enabled the autofs4 support. That means systemd tries to install the automount point, but can't do this.

Hence: enable autofs support, or completely disable the security support so that the sysfs directory for it goes away. 

Closing. Feel free to reopen if my guess isn't right.
Comment 3 Daniel Drake 2011-05-09 13:59:43 UTC
Kay, double-checked. /sys/kernel/security is not there.

I can't run the systemctl check due to the problem described at http://lists.freedesktop.org/archives/systemd-devel/2011-May/002253.html

Lennart, I have the kernel option for /sys/kernel/security disabled (so that directory doesn't appear), and I have autofs4 enabled. Attaching full kernel config now.
Comment 4 Daniel Drake 2011-05-09 14:00:28 UTC
Created attachment 46505 [details]
my kernel config
Comment 5 Lennart Poettering 2011-05-09 14:41:15 UTC
Try booting into emergency mode (i.e. pass "emergency" on the kernel cmdline), then start running "strace -f -p 1" and then start your service manually with systemctl. This should show you how the process is forked off, and which syscall fails.
Comment 6 Daniel Drake 2011-05-14 15:09:32 UTC
Created attachment 46725 [details]
strace log

Thanks, that will help me debug other issues as well.

Here's a strace capture where you can see the issue. Interesting bit starts at line 74 (where I run "systemctl start sys-kernel-security.automount")
Comment 7 Daniel Drake 2011-05-14 15:39:51 UTC
Oops, I overlooked something silly.

The ConditionPathExists in sys-kernel-security.automount was only added after systemd v26 was released, and I'm running v26 so the ConditionPathExists line isn't actually present.

If I add it manually, it works as expected.
sorry for the noise.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.