On 06/07/2017 12:08 PM, J. Bruce Fields wrote:
> On Wed, Jun 07, 2017 at 06:04:12AM -0400, Steve Dickson wrote:
>> # ps ax | grep mount
>> 980 ? Ss 0:00 /sbin/mount.nfs nfssrv:/home/tmp /mnt/tmp -o rw,bg
>
> Right, but I think we also need to see a "systemctl status
> remote-fs.target", or something, to verify whether that's the forked
> background process or just the foreground process that's still hanging
> up some part of the boot process (even though it's gotten far enough
> along that you can log in--unless logins aren't permitted till remote
> fs's are mounted, I don't know.)
It succeeds...
# systemctl status remote-fs.target
* remote-fs.target - Remote File Systems
Loaded: loaded (/usr/lib/systemd/system/remote-fs.target; enabled; vendor preset: enabled)
Active: active since Tue 2017-06-06 12:36:51 EDT; 12min ago
Docs: man:systemd.special(7)
Jun 06 12:36:51 f26 systemd[1]: Reached target Remote File Systems.
The reason being, as Neil pointed out, the mount.nfs gets the
ECONNREFUSED right away because the server is down. So a
child is quickly forked that continues to try the mount...
Basically sneaking around systemd back... Which is hard
to do... these day 8-)
steved.
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
