Red Hat Bugzilla – Bug 815727
/etc/fstab parser is confused by dead symlinks
Last modified: 2013-01-14 16:04:02 EST
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
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
Active: inactive (dead)
[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
Expected results: working autofs mountpoint
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.