Description of problem: At boot time, the following error appears in /var/log/messages: systemd[1]: Cannot add dependency job for unit autofs.target, ignoring: Unit autofs.target failed to load: No such file or directory. See system logs and 'systemctl status' for details. If I run "systemctl status", I get the error: "Too few arguments." If I then run "systemctl status autofs.target", I see a message which doesn't tell me anything about the problem: autofs.target Loaded: error Active: inactive (dead) If I then go to /var/log and do "grep autofs *", we see: messages:Apr 1 13:12:56 testvm kernel: [ 2.634507] systemd[1]: Cannot add dependency job for unit autofs.target, ignoring: Unit autofs.target failed to load: No such file or directory. See system logs and 'systemctl status' for details. If I run "systemctl status", I get the error: "Too few arguments." If I then run "systemctl status autofs.target", ... :) Perhaps the error message could be a little more specific and the default log level should be a little higher. As I've tried Fedora 15 Alpha this week, I've had a number of times where I had a hard time figuring out even the basics of what systemd was trying to start and what caused an error. Version-Release number of selected component (if applicable): systemd-22-1.fc15.x86_64
> Unit autofs.target failed to load: No such file or directory This one is pretty obvious. There is no autofs.target unit file anywhere in the configuration directories. > autofs.target > Loaded: error Yes, this confirms it. > See system logs and 'systemctl status' for details. Right, this message just raises false hopes :-) Could you do "systemctl dump" to find which unit references the non-existent autofs.target?
(In reply to comment #1) > Could you do "systemctl dump" to find which unit references the non-existent > autofs.target? Forget it. I already know what it is. /etc/init.d/autofs has this in its LSB header: # Provides: $autofs This gets mapped to autofs.target by systemd. systemd should not really expect to find a autofs.target unit file. The warning should not be printed in this case.
Created attachment 489816 [details] output from "systemctl dump"
There is not standardized ("reserved") facility name $autofs. The autofs LSB script should not use this. http://refspecs.freestandards.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/facilname.html
(In reply to comment #4) > There is not standardized ("reserved") facility name $autofs. > > The autofs LSB script should not use this. > > http://refspecs.freestandards.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/facilname.html Can you spell this out? What should the "Provides:" be set to?
It doesn't need to be set to anything, if I'm reading it right. SysV services automatically 'provide' their service name, so the script automatically provides 'autofs'. By prefixing it with '$', you're attempting to provide a standards-defined facility (which $autofs isn't.)
Created attachment 490149 [details] Patch - fix lsb service name in init script
Does the above patch help? Please try the scratch build at (and report back): http://people.redhat.com/~ikent/autofs-5.0.5-35.bz692963.2.fc15
Ian, this new package made the message go away. Thanks for looking into this. By the way, it looks like there is a minor problem with the version number on the experimental package: [root@testvm ~]# rpm -Uvh http://people.redhat.com/~ikent/autofs-5.0.5-35.bz692963.2.fc15/autofs-5.0.5-35.bz692963.2.fc15.x86_64.rpm Retrieving http://people.redhat.com/~ikent/autofs-5.0.5-35.bz692963.2.fc15/autofs-5.0.5-35.bz692963.2.fc15.x86_64.rpm Preparing... ########################################### [100%] package autofs-1:5.0.5-35.fc15.x86_64 (which is newer than autofs-1:5.0.5-35.bz692963.2.fc15.x86_64) is already installed [root@testvm ~]# I ended up getting it to work with "--oldpackage", but I thought I should mention it.
Yes, patch looks good. Provides: autofs is exactly the right thing, and without the line things would have worked, too.
I wans't able to access my NAS at home using autofs. The patch fixes this issue for me.
Patched packets also seem to work for me. Error refering to "autofs.target" is no longer logged (does no longer happen?). So it looks like the patch helps it ...
*** Bug 710589 has been marked as a duplicate of this bug. ***
autofs-5.0.5-38.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/autofs-5.0.5-38.fc15
Package autofs-5.0.5-38.fc15: * should fix your issue, * was pushed to the Fedora 15 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing autofs-5.0.5-38.fc15' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/autofs-5.0.5-38.fc15 then log in and leave karma (feedback).
autofs-5.0.5-38.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.