jessie: help debugging NFS shares not mounted at boot, double mounts with mount -a, and @reboot cronjobs
Sandro Tosi
morph at debian.org
Wed Feb 10 17:37:46 GMT 2016
Disabling ifplugd didnt change the situation, and there are still missing
mount points
On Tue, Feb 9, 2016 at 9:21 PM, Michael Biebl <biebl at debian.org> wrote:
> Am 09.02.2016 um 22:11 schrieb Sandro Tosi:
>>> Another idea: maybe it's related to name resolution. How is that
>>> configured? Does it help if you use IP adresses in /etc/fstab?
>>
>> # cat /etc/resolv.conf
>> search OUR-DOMAIN.com
>> nameserver 127.0.0.1
>> nameserver XXX.YYY.32.33
>> nameserver XXX.YYY.32.22
>> options no_tld_query
>>
>> on localhost we have unbound as dns cache with this config
>>
>> # cat /etc/unbound/unbound.conf
>> server:
>> val-permissive-mode: yes
>> local-zone: "10.in-addr.arpa" nodefault
>> forward-zone:
>> name: .
>> forward-addr: XXX.YYY.32.33
>> forward-addr: XXX.YYY.32.22
>> remote-control:
>> control-enable: yes
>>
>> the NFS storage appliance we are using is configured to have a
>> multiple ip addresses to resolve to the same domain name, and it
>> automatically balances connections between clients providing different
>> ip addresses, so we cannot change that.
>
> For testing purposes, it should be possible to configure one client to
> use a fixed IP address in /etc/fstab.
oh yes, totally. I just tried that (with ifplugd still disabled) and...
> If the mount then doesn't fail,
> you have narrowed down the problem then at least.
... sadly now all the nfs shares fail to mount at first:
Feb 10 12:08:27 SERVER kernel: RPC: Registered tcp NFSv4.1 backchannel
transport module.
Feb 10 12:08:27 SERVER kernel: FS-Cache: Netfs 'nfs' registered for caching
Feb 10 12:08:27 SERVER kernel: NFS: Registering the id_resolver key type
Feb 10 12:08:27 SERVER kernel: Installing knfsd (copyright (C) 1996
okir at monad.swb.de).
Feb 10 12:08:30 SERVER kernel: igb 0000:01:00.0 eth0: igb: eth0 NIC Link is
Up 1000 Mbps Full Duplex, Flow Control: RX
Feb 10 12:08:30 SERVER mount[576]: mount to NFS server 'XXX.YYY.21.22'
failed: No route to host, retrying
Feb 10 12:08:30 SERVER mount[567]: mount to NFS server 'XXX.YYY.27.74'
failed: No route to host, retrying
Feb 10 12:08:30 SERVER mount[578]: mount to NFS server 'XXX.YYY.16.226'
failed: No route to host, retrying
Feb 10 12:08:30 SERVER mount[582]: mount to NFS server 'XXX.YYY.26.132'
failed: No route to host, retrying
Feb 10 12:08:30 SERVER mount[574]: mount to NFS server 'XXX.YYY.36.210'
failed: No route to host, retrying
Feb 10 12:08:30 SERVER mount[572]: mount to NFS server 'XXX.YYY.27.74'
failed: No route to host, retrying
Feb 10 12:08:30 SERVER mount[583]: mount to NFS server 'XXX.YYY.32.75'
failed: No route to host, retrying
Feb 10 12:08:30 SERVER mount[569]: mount to NFS server 'XXX.YYY.32.111'
failed: No route to host, retrying
Feb 10 12:08:30 SERVER mount[564]: mount to NFS server 'XXX.YYY.20.176'
failed: No route to host, retrying
Feb 10 12:08:30 SERVER mount[580]: mount to NFS server 'XXX.YYY.20.176'
failed: No route to host, retrying
Feb 10 12:08:30 SERVER mount[561]: mount.nfs: backgrounding
"XXX.YYY.20.176:/VOL"
Feb 10 12:08:30 SERVER mount[562]: mount.nfs: backgrounding
"XXX.YYY.27.74:/VOL"
Feb 10 12:08:30 SERVER mount[563]: mount.nfs: backgrounding
"XXX.YYY.32.111:/VOL"
Feb 10 12:08:30 SERVER mount[565]: mount.nfs: backgrounding
"XXX.YYY.27.74:/VOL"
Feb 10 12:08:30 SERVER mount[568]: mount.nfs: backgrounding
"XXX.YYY.36.210:/VOL"
Feb 10 12:08:30 SERVER mount[573]: mount.nfs: backgrounding
"XXX.YYY.21.22:/VOL"
Feb 10 12:08:30 SERVER mount[575]: mount.nfs: backgrounding
"XXX.YYY.16.226:/VOL"
Feb 10 12:08:30 SERVER mount[579]: mount.nfs: backgrounding
"XXX.YYY.26.132:/VOL"
Feb 10 12:08:30 SERVER mount[581]: mount.nfs: backgrounding
"XXX.YYY.32.75:/VOL"
Feb 10 12:08:30 SERVER mount[577]: mount.nfs: backgrounding
"XXX.YYY.20.176:/VOL"
Feb 10 12:08:30 SERVER nfs-common[612]: Starting NFS common utilities:
statd idmapd.
but just above all these failures, the eth0 is marked as UP.
in the critical-chain now I no longer see the remote-fs target (so I'm not
sure when it is started in relation with the networking target), is it
normal?
# systemd-analyze critical-chain
The time after the unit is active or started is printed after the "@"
character.
The time the unit takes to start is printed after the "+" character.
graphical.target @59.006s
└─multi-user.target @59.006s
└─getty.target @59.005s
└─getty at tty1.service @59.005s
└─rc-local.service @5.259s +53.740s
└─basic.target @5.254s
└─paths.target @5.254s
└─acpid.path @5.254s
└─sysinit.target @5.253s
└─nfs-common.service @1.614s +3.639s
└─rpcbind.target @1.614s
└─rpcbind.service @1.586s +27ms
└─network-online.target @1.585s
└─network.target @1.585s
└─networking.service @250ms +1.335s
└─local-fs.target @249ms
└─var-lib-hugetlbfs-global-pagesize\x2d2MB.mount
@5.271s
└─local-fs-pre.target @238ms
└─systemd-remount-fs.service @234ms +3ms
└─keyboard-setup.service @152ms +81ms
└─systemd-udevd.service @149ms +2ms
└─systemd-tmpfiles-setup-dev.service
@123ms +26ms
└─kmod-static-nodes.service @113ms
+6ms
└─system.slice @110ms
└─-.slice @110ms
>
> As a next step, I would remove the caching server from /etc/resolv.conf
> and let the system talk directly to your name server(s) which are
> responsible for resolving the name of the NFS server and retry with a
> FQDN in /etc/fstab.
>
>
> --
> Why is it that all of the instruments seeking intelligent life in the
> universe are pointed away from Earth?
>
--
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
G+: https://plus.google.com/u/0/+SandroTosi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20160210/5eca928b/attachment-0002.html>
More information about the Pkg-systemd-maintainers
mailing list