Description of problem: If I manually stop an automount with "systemctl stop foo.automount" then it will be reactivated the next time the tmpfiles cleaner runs. Version-Release number of selected component (if applicable): systemd-195-15.fc18.x86_64 How reproducible: Every time. Steps to Reproduce: 1. Stop automount 2. Wait for tmpfiles cleaner to run 3. Note that automount is running again Actual results: Automount restarts. Expected results: Automount stays stopped. Additional info: I think is is caused by "Wants=local-fs.target" in the tmpfiles cleaner unit. The relevant log messages are: Jan 16 08:57:11 bristol.example.com sudo[9274]: thh : TTY=pts/1 ; PWD=/etc/rc.d/init.d ; USER=root ; COMMAND=/bin/systemctl stop data.automount Jan 16 08:57:11 bristol.example.com systemd[1]: Stopping Local File Systems. Jan 16 08:57:11 bristol.example.com systemd[1]: Stopped target Local File Systems. Jan 16 08:57:11 bristol.example.com systemd[1]: Stopping data.automount. Jan 16 08:57:11 bristol.example.com systemd[1]: Unset automount data.automount. ... Jan 15 17:30:49 bristol.example.com systemd[1]: Started File System Check on Root Device. Jan 15 17:30:49 bristol.example.com systemd[1]: Started Import network configuration from initramfs. Jan 15 17:30:49 bristol.example.com systemd[1]: Starting data.automount. Jan 15 17:30:49 bristol.example.com systemd[1]: Set up automount data.automount. Jan 15 17:30:49 bristol.example.com systemd[1]: Starting Local File Systems. Jan 15 17:30:49 bristol.example.com systemd[1]: Reached target Local File Systems. Jan 15 17:30:49 bristol.example.com systemd[1]: Starting Cleanup of Temporary Directories... Jan 15 17:30:49 bristol.example.com systemd-tmpfiles[30720]: stat(/run/user/2067/gvfs) failed: Permission denied Jan 15 17:30:50 bristol.example.com systemd[1]: Started Cleanup of Temporary Directories.
This message is a reminder that Fedora 18 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 18. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '18'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 18's end of life. Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 18 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 18's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Is this reproducible today? Is it possible that you have some tmpfiles rules in place that reference the autofs mount of yours?
Yes, it still seems to happen. I changed systemd-tmpfiles-clean.timer to run every five minutes, then stopped data.old.mount and data.old.automount and waited for the next timer run, and this is what happened: Jun 20 14:02:16 bristol.example.com systemd[1]: Starting data.old.automount. Jun 20 14:02:16 bristol.example.com systemd[1]: Set up automount data.old.automount. Jun 20 14:02:16 bristol.example.com systemd[1]: Starting Local File Systems. Jun 20 14:02:16 bristol.example.com systemd[1]: Reached target Local File Systems. Jun 20 14:02:16 bristol.example.com systemd[1]: Starting Cleanup of Temporary Directories... Jun 20 14:02:16 bristol.example.com systemd[1]: Started Cleanup of Temporary Directories. There are no tmpfiles.d rules referencing anything on that mount. The "Starting Local File Systems" and "Reached target Local File Systems" messages are an indication that local-fs.target is being triggered.
This is not really related to automounts, but is a basic property of how target works. Any unit which is started with DefaultDependencies=yes will pull in local-fs.target, and since local-fs.target Requires=data.old.automount, it will get started. Sometimes this is indeed not what you want, but it is the expected behaviour.
This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle. Changing version to '23'. (As we did not run this process for some time, it could affect also pre-Fedora 23 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23
This is not reproducible anymore (F22).