Description of problem: I switched from /etc/systemd/system/foo.[auto,]mount to a line in /etc/fstab. Systemd doesn't recognize the new entry after systemctl daemon-reload. Version-Release number of selected component (if applicable): systemd.x86_64-44-4.fc17 How reproducible: always Steps to Reproduce: 1. have /etc/systemd/system/home-jan-server.[auto,]mount files 2. remove files 3. add same entry to /etc/fstab Actual results: /etc/fstab: dockstar:/mnt/storage /home/jan/server nfs noauto,comment=systemd.automount 0 0 [jan@jan ~]$ sudo systemctl start home-jan-server.automount Job failed. See system journal and 'systemctl status' for details. [jan@jan ~]$ systemctl status home-jan-server.automount home-jan-server.automount Loaded: loaded Active: inactive (dead) Where: /home/jan/server [jan@jan ~]$ systemctl status home-jan-server.mount home-jan-server.mount - /home/jan/server Loaded: error (Reason: No such file or directory) Active: inactive (dead) since Tue, 24 Apr 2012 13:22:28 +0200; 28s ago Where: /home/jan/server What: dockstar:/mnt/storage CGroup: name=systemd:/system/home-jan-server.mount Expected results: working autofs mountpoint Additional info:
I had a dead symlink /etc/systemd/system/remote-fs.target.wants/home-jan-server.automount lying around, which confused systemd. After removing that symlink and reloading systemd, it actually works fine.
Were there any complaints logged from systemd in /var/log/messages about the symlink?
no, none. I discovered it myself with find /etc -name ...
This seems to be a serious bug. what is the recovery for this? a reboot? That's what I have to do. is there some command to run that will do this? If you don't fix the bug, please document a workaround. I think also it should reread /etc/fstab when one leaves the emergency mode shell. Or why not inotify /etc/fstab and reread it when it changes.
Unit files in /etc (even if they are in a .wants/ subdir) take precedence over fstab, so I guess everything was handled correctly here. Closing.