Disabling ifplugd didnt change the situation, and there are still missing mount points
On Tue, Feb 9, 2016 at 9:21 PM, Michael Biebl <[email protected]> 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 [email protected]). 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 └─[email protected] @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
_______________________________________________ Pkg-systemd-maintainers mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
