Hi,
I have opensuse 13.2 running as openldap and autofs client.
I have success to configure pc for sssd for openldap and autofs via sssd
from the journalctl, it will randomly show
Dec 15 18:40:47 rhine kernel: lockd: server 192.168.2.32 not responding, still trying
Dec 15 18:40:47 rhine kernel: lockd: server 192.168.2.32 OK
Thanks.
Hi,
anyone could help me on this ?
I have Mageia 2 running as OpenLDAP and NFS server. Below is the nfsstat
[root@penguin ~]# nfsstat
Server rpc stats:
calls badcalls badclnt badauth xdrcall
8550618 0 0 0 0
Server nfs v2:
null getattr setattr root lookup readlink
14 100% 0 0% 0 0% 0 0% 0 0% 0 0%
read wrcache write create remove rename
0 0% 0 0% 0 0% 0 0% 0 0% 0 0%
link symlink mkdir rmdir readdir fsstat
0 0% 0 0% 0 0% 0 0% 0 0% 0 0%
Server nfs v3:
null getattr setattr lookup access readlink
872 0% 3262622 43% 82014 1% 1451935 19% 302328 4% 466 0%
read write create mkdir symlink mknod
1390703 18% 269727 3% 164663 2% 3478 0% 188 0% 1129 0%
remove rmdir rename link readdir readdirplus
164893 2% 3230 0% 19155 0% 3782 0% 32310 0% 43143 0%
fsstat fsinfo pathconf commit
10394 0% 1644 0% 10 0% 224587 3%
Server nfs v4:
null compound
5 0% 701943 99%
Server nfs v4 operations:
op0-unused op1-unused op2-future access close commit
0 0% 0 0% 0 0% 184559 9% 27635 1% 145 0%
create delegpurge delegreturn getattr getfh link
132 0% 0 0% 3062 0% 506424 25% 107673 5% 7 0%
lock lockt locku lookup lookup_root nverify
4022 0% 11 0% 3285 0% 268638 13% 0 0% 0 0%
open openattr open_conf open_dgrd putfh putpubfh
30827 1% 0 0% 701 0% 162 0% 701756 36% 0 0%
putrootfh read readdir readlink remove rename
25 0% 12413 0% 11679 0% 54 0% 3007 0% 1127 0%
renew restorefh savefh secinfo setattr setcltid
187 0% 29909 1% 32093 1% 0 0% 4526 0% 7 0%
setcltidconf verify write rellockowner bc_ctl bind_conn
7 0% 0 0% 13674 0% 1101 0% 0 0% 0 0%
exchange_id create_ses destroy_ses free_stateid getdirdeleg getdevinfo
0 0% 0 0% 0 0% 0 0% 0 0% 0 0%
getdevlist layoutcommit layoutget layoutreturn secinfononam sequence
0 0% 0 0% 0 0% 0 0% 0 0% 0 0%
set_ssv test_stateid want_deleg destroy_clid reclaim_comp
0 0% 0 0% 0 0% 0 0% 0 0%
Client rpc stats:
calls retrans authrefrsh
0 0 0
At opensuse 13.2 client side,
Jan 24 07:55:09 tachyon kernel: lockd: server 192.168.1.32 not responding, still trying
Jan 24 07:55:09 tachyon kernel: lockd: server 192.168.1.32 OK
Jan 24 08:05:50 tachyon kernel: lockd: server 192.168.1.32 not responding, still trying
Jan 24 08:05:50 tachyon kernel: lockd: server 192.168.1.32 OK
Jan 24 08:14:15 tachyon kernel: lockd: server 192.168.1.32 not responding, still trying
Jan 24 08:14:15 tachyon kernel: lockd: server 192.168.1.32 OK
Jan 24 08:51:39 tachyon kernel: lockd: server 192.168.1.32 not responding, still trying
Jan 24 08:51:39 tachyon kernel: lockd: server 192.168.1.32 OK
Jan 24 08:56:12 tachyon kernel: nfs: server 192.168.1.32 not responding, still trying
Jan 24 08:56:20 tachyon kernel: nfs: server 192.168.1.32 not responding, still trying
Jan 24 08:56:23 tachyon kernel: nfs: server 192.168.1.32 not responding, still trying
Jan 24 08:56:50 tachyon kernel: nfs: server 192.168.1.32 not responding, still trying
Jan 24 08:59:53 tachyon kernel: nfs: server 192.168.1.32 not responding, still trying
Jan 24 13:02:35 tachyon kernel: lockd: cannot unmonitor 192.168.1.32
Jan 26 07:59:04 tachyon kernel: lockd: server 192.168.1.32 not responding, still trying
Jan 26 07:59:04 tachyon kernel: lockd: server 192.168.1.32 OK
Jan 26 08:10:04 tachyon kernel: lockd: server 192.168.1.32 not responding, still trying
Jan 26 08:10:04 tachyon kernel: lockd: server 192.168.1.32 OK
thanks
Hi, there always a message, xprt_adjust_timeout: rq_timeout = 0! before lockd.
Feb 04 08:04:21 tachyon kernel: xprt_adjust_timeout: rq_timeout = 0!
Feb 04 08:04:21 tachyon kernel: lockd: server 192.168.1.32 not responding, still trying
Feb 04 08:04:21 tachyon kernel: lockd: server 192.168.1.32 OK
any idea ?
Thanks.
All,
I’m running into the same problems. My environment had a 32bit opensuse 13.1 and a number of 13.2 clients. The server died and I installed a new (64bit) server opensuse 13.1.
Everything works now except that the clients are extremely slow if login as a normal user (using yp en automounter).
If I login as root on a client it performs as expected.
Anybody found a solution??? or any other trick/tip
[ul]
[li]Are you running the NFS Client parallel to the automounter?[/li][LIST]
[li]If there are no NFS Client mounts mentioned in fstab then the systemd nfs.service should be disabled. [/li][/ul]
[li]Is the DNS setup and running correctly? [/li][li]The NFS Server is offering NFS V3 and NFS V4 – for the case of NFS V4, is Kerberos setup and running correctly? [/li][/LIST]
NFS client is running next to automounter, there are two filesystems to be mounted.
DNS and DHCP are working correctly as far as I can detect.
Just NFS v3
i just created a vbox to do some extra debugging/tracing. But even this vbox is slow.
Any tips and or trics are appreciated 
Some more info about my environment:
The (nfs/nis/dns/dhcpd/file) server does not report any thing unusual in the log.
The client reports the following during boot:
Nov 29 09:48:48 opensuse-vb kernel: xprt_adjust_timeout: rq_timeout = 0!
Nov 29 09:48:48 opensuse-vb kernel: lockd: server schuurpc not responding, still trying
Nov 29 09:48:49 opensuse-vb kernel: xprt_adjust_timeout: rq_timeout = 0!
Nov 29 09:48:49 opensuse-vb kernel: lockd: server schuurpc not responding, still trying
Nov 29 09:48:49 opensuse-vb kernel: lockd: server schuurpc OK
Nov 29 09:48:49 opensuse-vb kernel: lockd: server schuurpc OK
Nov 29 09:50:09 opensuse-vb dbus[640]: [system] Activating via systemd: service name='org.freedesktop.UPower' unit='upower.service'
Note the delay between the last two lines!!
The behaviour is that if I login as normal user (nis authentication and automounting home directory) the system is very slow in everything. However login in as root … it performs as expected.
It seems that in ubuntu they had more or less the same (I’m not an expert so hard to judge for me 
)https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1358226 and resolved it.
Any tips and trics are highly appreciated!!
Since I’ve set-up to only use the automounter – no NFS Client mounts in fstab – and killed the NFS Client service, the automounter on this 13.2 system and a Leap 42.1 system both react fast – quite fast – no perceptible delay . . .
I suspect that there may be an issue with having parallel NFS Client mounts in fstab and other NFS Client mounts via automounter.
We need more investigation to clarify this issue.
I used the automounter to mount /home and NFS to mount a number of other filesystems.
I have now mounted /home also via NFS and disabled the automounter.
Tests until now show that I have again the expected performance, that’s good but it’s just a workaround … I am not able find the root problem 
If there is anybody with enough knowledge who takes this behaviour as a challange … let me know!!
… what are your /etc/fstab entries for your NFS mounts?
– lawrence
Thread is over 6 months old