[Bug 875373] New: systemd-tmpfiles-setup.service runs before all filesystems are mounted
https://bugzilla.novell.com/show_bug.cgi?id=875373 https://bugzilla.novell.com/show_bug.cgi?id=875373#c0 Summary: systemd-tmpfiles-setup.service runs before all filesystems are mounted Classification: openSUSE Product: openSUSE Factory Version: 13.2 Milestone 0 Platform: Other OS/Version: openSUSE 13.2 Status: NEW Severity: Major Priority: P5 - None Component: Basesystem AssignedTo: systemd-maintainers@suse.de ReportedBy: suse-beta@cboltz.de QAContact: qa-bugs@suse.de Found By: Beta-Customer Blocker: --- - Factory, last updated yesterday - last known-working version: Factory from 2014-04-13 systemd-tmpfiles-setup.service runs before all filesystems are mounted. (Probably) since the change that makes /var/run a symlink to /run, the tmpdirs below /var/run can't be created on my system. Note: I have an encrypted /home partition, and /var is a symlink to /home/sys-var. This means /var becomes available after /home has been mounted. systemd-tmpfiles-setup.service should wait until _all_ filesystems are mounted. # systemctl status systemd-tmpfiles-setup.service systemd-tmpfiles-setup.service - Create Volatile Files and Directories Loaded: loaded (/usr/lib/systemd/system/systemd-tmpfiles-setup.service; static) Active: active (exited) since So 2014-04-27 11:44:45 CEST; 29min ago Docs: man:tmpfiles.d(5) man:systemd-tmpfiles(8) Process: 1491 ExecStart=/usr/bin/systemd-tmpfiles --create --remove --boot --exclude-prefix=/dev (code=exited, status=0/SUCCESS) Main PID: 1491 (code=exited, status=0/SUCCESS) CGroup: /system.slice/systemd-tmpfiles-setup.service Apr 27 11:44:45 geeko systemd-tmpfiles[1491]: Failed to create directory /var/run/samba: No such file or directory Apr 27 11:44:45 geeko systemd-tmpfiles[1491]: Failed to create directory /var/run/svnserve: No such file or directory [... and some more /var/run/* directories with similar error message ...] Apr 27 11:44:45 geeko systemd[1]: Started Create Volatile Files and Directories. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=875373 https://bugzilla.novell.com/show_bug.cgi?id=875373#c1 Thomas Blume <thomas.blume@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED CC| |systemd-maintainers@suse.de | |, thomas.blume@suse.com AssignedTo|systemd-maintainers@suse.de |thomas.blume@suse.com --- Comment #1 from Thomas Blume <thomas.blume@suse.com> 2014-04-28 08:31:44 UTC --- The purpose of making /var/run a symlink to run is FHS compliance. For details, see the FHS compliance section at: http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard Seems you are overwriting this symlink when providing /var as a symlink to the encrypted home. So you should be aware that your system might not be FHS compliant with this setup. However, systemd-tmpfiles-setup.service has a dependency to local-fs.target. This includes the mount of /home. Still, cryptsetup.target starts only after local-fs.target. It could work if we make systemd-tmpfiles-setup.service depending on cryptsetup.target. But this requires that cryptsetup.target doesn't depend on any directory that systemd-tmpfiles-setup.service creates. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=875373 https://bugzilla.novell.com/show_bug.cgi?id=875373#c2 --- Comment #2 from Dr. Werner Fink <werner@suse.com> 2014-04-28 08:33:57 UTC --- Partly agree ... IMHIO this service requires a split that is a systemd-pre-tmpfiles-setup.service -> doing the /var/run symlink to /run mount all file systems systemd-tmpfiles-setup.service -> set up the tmp files this is also valid for SLES12(!) ... -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=875373 https://bugzilla.novell.com/show_bug.cgi?id=875373#c3 --- Comment #3 from Christian Boltz <suse-beta@cboltz.de> 2014-04-28 13:34:18 CEST --- (In reply to comment #1) # ls -l /var /var/run lrwxrwxrwx 1 root root 13 25. Jul 2009 /var -> home/sys-var// lrwxrwxrwx 1 root root 4 26. Apr 22:50 /var/run -> /run/ So my /var/run _is_ a symlink as expected - but it needs /home mounted to be available. (AFAIK the FHS does not forbid that /var is a symlink, right? ;-) (In reply to comment #2)
Partly agree ... IMHIO this service requires a split that is a [...]
Can we please change the order so that "mount all file systems" comes first (before creating the /var/run symlink)? (But: the /var/run symlink should never be deleted, therefore I wonder why it needs to be created ;-) BTW: This bug seems to be a race condition - today's boot worked without problems... -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=875373 https://bugzilla.novell.com/show_bug.cgi?id=875373#c4 Dr. Werner Fink <werner@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |NEEDINFO InfoProvider| |suse-beta@cboltz.de --- Comment #4 from Dr. Werner Fink <werner@suse.com> 2014-04-28 11:38:54 UTC --- (In reply to comment #3) Looks somehow broken ... Why are you redirecting /var to /home/sys-var instead of using a (re)bind mount or similar? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=875373 https://bugzilla.novell.com/show_bug.cgi?id=875373#c5 --- Comment #5 from Thomas Blume <thomas.blume@suse.com> 2014-04-28 13:33:16 UTC --- I still see a problem with ordering here. /home is a directory not required in the init process, but /var (resp. /run) is. Making /var depending on the availability of /home is IMHO not quite correct. In order to fullfill this, you will need to make /home available as early as the mounts required for the init process. In order to do so, you could use the rd.luks parameters to enable the crypsetup of /home from within the initrd. (see details at: http://www.freedesktop.org/software/systemd/man/systemd-cryptsetup-generator...) This should be early enough to not conflict with the systemd-tmpfiles-setup.service. However, if you really want to make sure that the crypt setup is done before the tmpfiles get created, you need to add a dependency in in /usr/lib/systemd/system/systemd-tmpfiles-setup.service, e.g. change: After=systemd-readahead-collect.service systemd-readahead-replay.service local-fs.target into: After=systemd-readahead-collect.service systemd-readahead-replay.service local-fs.target cryptsetup.target Still, this can only be a custom setup, because if a user is not using crypted devices, cryptsetup.target wouldn't be active and this dependency should fail. Can you try wheter either of these suggestions work? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=875373 https://bugzilla.novell.com/show_bug.cgi?id=875373#c6 Christian Boltz <suse-beta@cboltz.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |ASSIGNED InfoProvider|suse-beta@cboltz.de | --- Comment #6 from Christian Boltz <suse-beta@cboltz.de> 2014-05-05 13:18:33 CEST --- (In reply to comment #4)
Looks somehow broken ... Why are you redirecting
/var to /home/sys-var
instead of using a (re)bind mount or similar?
Counter-question - what's wrong with a symlink? ;-) Seriously: mounting /home in the initrd ("initrd" flag in /etc/crypttab) solves the problem. Nevertheless, I still think local-fs.target should include "all encrypted filesystems mounted". -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=875373 https://bugzilla.novell.com/show_bug.cgi?id=875373#c7 Thomas Blume <thomas.blume@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |NEEDINFO InfoProvider| |suse-beta@cboltz.de --- Comment #7 from Thomas Blume <thomas.blume@suse.com> 2014-05-05 12:40:43 UTC ---
Nevertheless, I still think local-fs.target should include "all encrypted filesystems mounted".
The problem is that already the mount of encrypted file systems requires the presence of (/var)/run. systemd-tmpfiles-setup.service creates amongst others the directory: /run/systemd/ask-password (see /usr/lib/tmpfiles.d/systemd.conf). This directory is used in turn by systemd password agents that ask for passwords of encrypted file systems (see details at http://www.freedesktop.org/wiki/Software/systemd/PasswordAgents/). So, you will have a cyclic dependency between the encrypted filesystem that provide /var/run (and the symlink to /run) and the password agent that needs /run, in order to get the password for mounting the file system. Interestingly it seems to work on your system as you apparently have no problem getting a password prompt for your /home. However, I guess this is because there is already a directory /run/systemd/ask-password before your /home gets mounted (this is also the case when mounting /home from within the initrd). Still, this is not really the way how things should be. You are welcome to provide any idea how to avoid such cyclic dependencies, but currently I don't see any possibility. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=875373 https://bugzilla.novell.com/show_bug.cgi?id=875373#c8 Christian Boltz <suse-beta@cboltz.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |ASSIGNED InfoProvider|suse-beta@cboltz.de | --- Comment #8 from Christian Boltz <suse-beta@cboltz.de> 2014-05-05 23:00:22 CEST --- (In reply to comment #7)
Nevertheless, I still think local-fs.target should include "all encrypted filesystems mounted".
The problem is that already the mount of encrypted file systems requires the presence of (/var)/run.
Which one - /run or /var/run ? (I know that they are basically the same if the /var/run symlink is available, but it would still be interesting which one is used in the code. If /var is not available yet, there's a big difference between /run and /var/run ;-)
systemd-tmpfiles-setup.service creates amongst others the directory: /run/systemd/ask-password (see /usr/lib/tmpfiles.d/systemd.conf).
Directories in /run are not a problem - /run is part of my (not encrypted) / partition and therefore available from the beginning.
Interestingly it seems to work on your system as you apparently have no problem getting a password prompt for your /home.
As long as it only needs /run (and not /var/run), there's no problem.
You are welcome to provide any idea how to avoid such cyclic dependencies, but currently I don't see any possibility.
As I wrote in my initial comment, I only had problems with openvpn. I'd guess the problem is that openvpn a) uses /var/run (not just /run) and b) tries to start before my /home (which also contains /var/ and its subdirectories) is mounted for a), /usr/lib/tmpfiles.d/openvpn.conf confirms my guess: D /var/run/openvpn 0750 root root - I still think the solution is to redefine local-fs.target to "all filesystems (including encrypted ones) are mounted". Asking for the password of encrypted partition(s) should happen after all non-encrypted partitions are mounted (in theory "/ and the /run tmpfs are mounted" should already be enough), and local-fs.target should wait for the encrypted partitions. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=875373 https://bugzilla.novell.com/show_bug.cgi?id=875373#c9 Dr. Werner Fink <werner@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |NEEDINFO InfoProvider| |suse-beta@cboltz.de --- Comment #9 from Dr. Werner Fink <werner@suse.com> 2014-05-06 06:42:32 UTC --- (In reply to comment #8) Hmm ... could you try to change the openvpn service that is to make it depend on local-fs.target? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=875373 https://bugzilla.novell.com/show_bug.cgi?id=875373#c10 --- Comment #10 from Thomas Blume <thomas.blume@suse.com> 2014-05-06 07:49:07 UTC ---
Which one - /run or /var/run ?
It is /run.
Directories in /run are not a problem - /run is part of my (not encrypted) / partition and therefore available from the beginning.
Ok, this explains why it works on your machine. But what happens if /run is not part of /? Your comment already includes a cyclic dependency:
Asking for the password of encrypted partition(s) should happen after all non-encrypted partitions are mounted
So, cryptsetup.target needs to wait for local-fs.target.
and local-fs.target should wait for the encrypted partitions.
So, local-fs.target needs to wait for cryptsetup.target. This cycle could IMHO only be solved by an additional target that depends on both local-fs.target and cryptsetup.target. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=875373 https://bugzilla.novell.com/show_bug.cgi?id=875373#c11 Christian Boltz <suse-beta@cboltz.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |ASSIGNED InfoProvider|suse-beta@cboltz.de | --- Comment #11 from Christian Boltz <suse-beta@cboltz.de> 2014-05-18 21:32:04 CEST --- (In reply to comment #10)
Directories in /run are not a problem - /run is part of my (not encrypted) / partition and therefore available from the beginning.
Ok, this explains why it works on your machine. But what happens if /run is not part of /?
/run is never part of / - it's a tmpfs (IIRC since some releases) and therefore always available.
Your comment already includes a cyclic dependency: [...] This cycle could IMHO only be solved by an additional target that depends on both local-fs.target and cryptsetup.target.
Basically yes - something like a all-filesystems.target. In practise, the better way would probably be: - rename local-fs.target to local-fs-unencrypted.target - create a new local-fs.target that includes local-fs-unencrypted.target and cryptsetup.target This way would have the advantage that all the units that depend on local-fs.target are "automagically" fixed. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=875373 http://bugzilla.novell.com/show_bug.cgi?id=875373#c12 Thomas Blume <thomas.blume@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|CONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #12 from Thomas Blume <thomas.blume@suse.com> --- OpenSUSE 13.2 is quite outdated by now. I need to close this bug. If you rediscover this problem in the current openSUSE version, please open a new one. -- You are receiving this mail because: You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply＠novell.com