Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

zfs-mount.service WorkingDirectory ignored (Not an absolute path) #6429

Closed
LnxGnome opened this issue Jul 30, 2017 · 10 comments · Fixed by #6437
Closed

zfs-mount.service WorkingDirectory ignored (Not an absolute path) #6429

LnxGnome opened this issue Jul 30, 2017 · 10 comments · Fixed by #6437

Comments

@LnxGnome
Copy link

System information

Type Version/Name
Distribution Name CentOS
Distribution Version 7.3
Linux Kernel 3.10.0-514.26.2
Architecture x86_64
ZFS Version 0.7.0-1
SPL Version 0.7.0-1

Describe the problem you're observing

Seen in journalctl output:
systemd[1]: [/usr/lib/systemd/system/zfs-mount.service:14] Not an absolute path, ignoring: -/sbin/

Describe how to reproduce the problem

Install ZFS on CentOS 7.3 (this system was upgraded from 0.6.5)

other info

man systemd.exec
WorkingDirectory=
Takes an absolute directory path. Sets the working directory for executed processes. If not set, defaults to the root directory when systemd is running as a system instance and the respective user's home directory if run as user.

@loli10K
Copy link
Contributor

loli10K commented Jul 30, 2017

https://www.freedesktop.org/software/systemd/man/systemd.exec.html#WorkingDirectory=

WorkingDirectory=

Takes a directory path relative to the service's root directory specified by RootDirectory=, or the special value "~ ". Sets the working directory for executed processes. If set to "~", the home directory of the user specified in User= is used. If not set, defaults to the root directory when systemd is running as a system instance and the respective user's home directory if run as user. If the setting is prefixed with the "-" character, a missing working directory is not considered fatal. If RootDirectory=/RootImage= is not set, then WorkingDirectory= is relative to the root of the system running the service manager. Note that setting this parameter might result in additional dependencies to be added to the unit (see above).

@loli10K
Copy link
Contributor

loli10K commented Jul 30, 2017

This may be a systemd bug introduced in systemd/systemd@7b07e99.

@LnxGnome which systemd version is your system running?

@LnxGnome
Copy link
Author

systemd-219-30.el7_3.9.x86_64

@loli10K
Copy link
Contributor

loli10K commented Jul 31, 2017

Reproduced on CentOS7, cannot reproduce on Debian8 (systemd-215-17) or Sid (sytemd-234-2).

Also the "~" character doesn't seem to be accepted too:

centos systemd[1]: [/usr/lib/systemd/system/zfs-mount.service:15] Not an absolute path, ignoring: ~

Sorry but this doesn't seem a ZFS bug, maybe it's better to report this to your distro maintainer?

@LnxGnome
Copy link
Author

Looks like that functionality was introduced into systemd @ systemd/systemd@5f5d8ea (Sep 23, 2015), which would make it part of the v227 release of systemd (Oct 7, 2015). CentOS is on v219, so it would not be present.

@loli10K
Copy link
Contributor

loli10K commented Jul 31, 2017

@LnxGnome you're right, i had erroneously assumed CentOS had this functionality backported. Debian Jessie comes with systemd v215 but seems to support both "-" and "~".

@behlendorf
Copy link
Contributor

Is there a simple proposed for the older versions of systemd.

@LnxGnome
Copy link
Author

Don't set it. "If not set, defaults to the root directory when systemd is running as a system instance..."
Since ExecStart is an absolute path, is there a reason to set it to /sbin?

@behlendorf
Copy link
Contributor

@LnxGnome this was done originally to work around some undesirable behavior in mount(8), commit d32d25c. We need to make sure the cwd is not root, in fact an empty directory would be best, to avoid a specific type of mount failure.

@LnxGnome
Copy link
Author

LnxGnome commented Aug 1, 2017

Dropping the "-" is the next most straightforward solution. /sbin should be there.
@sbindir@ might be an alternative, which from the rpm.spec is /sbin.
If you leave it as-is, then (has error, defaults to back /) doesn't that reintroduce the chance of undesirable behavior that d32d25c is supposed to avoid?

behlendorf pushed a commit that referenced this issue Aug 21, 2017
By default the mount(8) command, as invoked by 'zfs mount', will try
to resolve any path parameter in its canonical form: this could lead
to mount failures when the cwd contains a symlink having the same name
of the dataset being mounted.

Fix this by explicitly disabling mount(8) path canonicalization.

Reviewed-by: George Melikov <[email protected]>
Reviewed-by: Brian Behlendorf <[email protected]>
Signed-off-by: loli10K <[email protected]>
Closes #1791 
Closes #6429 
Closes #6437
tonyhutter pushed a commit that referenced this issue Aug 22, 2017
By default the mount(8) command, as invoked by 'zfs mount', will try
to resolve any path parameter in its canonical form: this could lead
to mount failures when the cwd contains a symlink having the same name
of the dataset being mounted.

Fix this by explicitly disabling mount(8) path canonicalization.

Reviewed-by: George Melikov <[email protected]>
Reviewed-by: Brian Behlendorf <[email protected]>
Signed-off-by: loli10K <[email protected]>
Closes #1791 
Closes #6429 
Closes #6437
Fabian-Gruenbichler pushed a commit to Fabian-Gruenbichler/zfs that referenced this issue Sep 29, 2017
By default the mount(8) command, as invoked by 'zfs mount', will try
to resolve any path parameter in its canonical form: this could lead
to mount failures when the cwd contains a symlink having the same name
of the dataset being mounted.

Fix this by explicitly disabling mount(8) path canonicalization.

Reviewed-by: George Melikov <[email protected]>
Reviewed-by: Brian Behlendorf <[email protected]>
Signed-off-by: loli10K <[email protected]>
Closes openzfs#1791 
Closes openzfs#6429 
Closes openzfs#6437
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants