On 10/14/2013 04:59 PM, T.C. Hollingsworth wrote:
>> nas:/backup      /mnt/backup          nfs     bg,user,_netdev 0 0
> 
> Okay, so the "bg" option is a little different from what most people
> refer to as automounting, in that it just repeatedly attempts to mount
> the share until it succeeds, whereas true automounting waits until you
> attempt to access the mount to even try to mount it.  Of course, this
> distinction matters very little to _you_, but it might indicate what
> systemd is getting wrong here.
> 
> I'm curious as to whether systemd even tracks the mount properly in
> this case.  Does `systemctl status mnt-backup.mount` indicate success
> or failure?

Well, now it's failing to mount on boot:

# systemctl status mnt-backup.mount -l
mnt-backup.mount - /mnt/backup
   Loaded: loaded (/etc/fstab)
   Active: failed (Result: exit-code) since Mon 2013-10-14 15:01:58 MDT;
2 days ago
    Where: /mnt/backup
     What: nas:/backup

Oct 14 15:01:58 office mount[1403]: mount.nfs: mount system call failed
Oct 14 15:01:58 office systemd[1]: mnt-backup.mount mount process
exited, code=exited status=32
Oct 14 15:01:58 office systemd[1]: Failed to mount /mnt/backup.
Oct 14 15:01:58 office systemd[1]: Unit mnt-backup.mount entered failed
state.

> 
> If it indicates success, systemd definitely should be tearing down the
> mount on shutdown.  (systemd by design is supposed to reverse
> Before/After deps for stop operations.)  Definitely file a bug in this
> instance.
> 
> If it indicates failure, systemd isn't getting informed that this
> mount actually succeeds.  You could file a bug against systemd
> regarding this, but their answer might just be "use real automounting
> if you want this to work properly." To do that, switch your "bg" mount
> option for "x-systemd.automount" and see if it gets unmounted properly
> on shutdown afterwards.
> 
> Their answer could just as easily be "yeah, we need to fix this", so
> please do file the bug anyway, if only for the benefit of others who
> might run into this.

I'll probably wait to reproduce it succeeding at boot before filing a BZ
about failing at shutdown...

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Reply via email to