* nfs-server (v4.x only) takes extra 6 minutes to start without rpcbind
@ 2016-09-01 11:22 james harvey
2016-09-02 0:50 ` james harvey
0 siblings, 1 reply; 5+ messages in thread
From: james harvey @ 2016-09-01 11:22 UTC (permalink / raw)
To: Linux NFS Mailing List
Up to date Arch. Kernel 4.7.2 (-1 Arch). nfs-utils 1.3.4 (-1 Arch).
No firewall running on this system.
Arch doesn't have any distribution-specific patches - it uses the
sourceforge source -
https://git.archlinux.org/svntogit/packages.git/tree/trunk?h=packages/nfs-utils
I started writing that an nfs-server configured for v4.x only would
never start if there was no rpcbind, BUT wound up finding out it does
start, it just takes ~ 6 minutes when with rpcbind it's "instant" /
less than 1 second.
"This" has been occurring since I started with NFS v4.x using
nfs-utils 1.3.2 & 1.3.3. By "this", I mean it looking to me like
nfs-server wouldn't start without rpcbind. It was probably just
starting delayed and I was impatient before 6 minutes.
I've found several posts from people saying nfs-server won't start
without rpcbind on v4.x only, so others have definitely ran into this,
just never gave it 6 minutes to finish, or maybe theirs never
finished.
Looks like there was a similar issue patched in 12/2013. Same issue
of rpcbind being needed for v4.x, but without rpcbind the problem was
a writing fd to kernel failure from rpc.nfsd, which appears to me to
have been fatal, and I'm not getting.
http://www.spinics.net/lists/linux-nfs/msg41053.html
This MAY answer the question - it's only visible for RedHat
subscribers, which I'm not - and I have no idea if on RHEL what
versions he has and if it includes the 12/2013 patch I mentioned -
https://access.redhat.com/solutions/902013
/run/sysconfig/nfs-utils is:
==========
RPCNFSDARGS="-N 2 -N 3 8"
RPCMOUNTDARGS="-N 2 -N 3"
STATDARGS=""
SMNOTIFYARGS=""
RPCIDMAPDARGS=""
RPCGSSDARGS=""
RPCSVCGSSDARGS=""
BLKMAPDARGS=""
GSS_USE_PROXY="yes"
==========
/proc/fs/nfsd/versions is: "-2 -3 +4 +4.1 +4.2"
/proc/fs/nfsd/threads is: "8"
Running defaults (just adding "-N 2 -N 3" to RPCNFSDARGS and
RPCMOUNTDOPTS in /etc/sysconfig/nfs), the NFS server starts fine like
this, with these enabled:
* proc-fs-nfsd.mount
* var-lib-nfs-rpc_pipefs.mount
* gssproxy.service
* nfs-blkmap.service
* nfs-config.service
* nfs-idmapd.service
* nfs-mountd.service
* nfs-server.service
* rpc-statd.service
* rpcbind.service
* rpcbind.socket
nfs-server starts right away:
==========
Sep 01 05:05:14 terra systemd[1]: Starting Preprocess NFS configuration...
Sep 01 05:05:14 terra systemd[1]: Started Preprocess NFS configuration.
==========
I'm running NFS v4.x only, and I'd like to be able to disable
everything not needed.
I can mask gssproxy.service, nfs-blkmap.service, and
rpc-statd.service, and the NFS server still starts instantly with just
these:
* proc-fs-nfsd.mount
* var-lib-nfs-rpc_pipefs.mount
* nfs-config.service
* nfs-idmapd.service
* nfs-mountd.service
* nfs-server.service
* rpcbind.service
* rpcbind.socket
Since I'm running NFS v4.x only, it's my understanding I should also
be able to mask rpcbind.service and rpcbind.socket and just run with
these:
* proc-fs-nfsd.mount
* var-lib-nfs-rpc_pipefs.mount
* nfs-config.service
* nfs-idmapd.service
* nfs-mountd.service
* nfs-server.service
But without rpcbind.service and rpcbind.socket, I get the 6 minute delay
# systemctl start nfs-config
# systemctl start proc-fs-nfsd.mount
[ 45.907749] RPC: Registered named UNIX socket transport module.
[ 45.907755] RPC: Registered udp transport module.
[ 45.907757] RPC: Registered tcp transport module.
[ 45.907759] RPC: Registered tcp NFSv4.1 backchannel transport module.
[ 45.943152] Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
# rpcdebug -m nfsd -s all
# systemctl start var-lib-nfs-rpc_pipefs.mount
# rpc.mountd --foreground --no-udp -N 2 -N 3
rpc.mountd: Version 1.3.3 starting
# rpc.idmapd -f -vvv
rpc.idmapd: Skipping configuration file "/etc/idmapd.conf": No such
file or directory
rpc.idmapd: libnfsidmap: Unable to determine the NFSv4 domain; Using
'localdomain' as the NFSv4 domain which means UIDs will be mapped to
the 'Nobody-User' user defined in /etc/idmapd.conf
rpc.idmapd: libnfsidmap: using (default) domain: localdomain
rpc.idmapd: libnfsidmap: Realms list: 'LOCALDOMAIN'
rpc.idmapd: libnfsidmap: loaded plugin
/usr/lib/libnfsidmap/nsswitch.so for method nsswitch
rpc.idmapd: Expiration time is 0 seconds.
rpc.idmapd: Opened /proc/net/rpc/nfs4.nametoid/channel
rpc.idmapd: Opened /proc/net/rpc/nfs4.idtoname/channel
rpc.idmapd: Unable to open '/proc/sys/fs/nfs/idmap_cache_timeout' to
set client cache expiration time to 0 seconds
{in journalctl}
Sep 01 06:37:19 terra rpc.idmapd[2342]: libnfsidmap: Unable to
determine the NFSv4 domain; Using 'localdomain' as the NFSv4 domain
which means UIDs will be mapped to the 'Nobody-User' user defined in
/etc/idmapd.conf
Sep 01 06:37:19 terra rpc.idmapd[2342]: libnfsidmap: using (default)
domain: localdomain
Sep 01 06:37:19 terra rpc.idmapd[2342]: libnfsidmap: Realms list: 'LOCALDOMAIN'
Sep 01 06:37:19 terra rpc.idmapd[2342]: libnfsidmap: loaded plugin
/usr/lib/libnfsidmap/nsswitch.so for method nsswitch
Sep 01 06:37:19 terra rpc.idmapd[2342]: Opened
/proc/net/rpc/nfs4.nametoid/channel
Sep 01 06:37:19 terra rpc.idmapd[2342]: Opened
/proc/net/rpc/nfs4.idtoname/channel
Sep 01 06:37:19 terra rpc.idmapd[2342]: Unable to open
'/proc/sys/fs/nfs/idmap_cache_timeout' to set client cache expiration
time to 0 seconds
# exportfs -r
# rpc.nfsd --debug --no-udp -N 2 -N 3 8
rpc.nfsd: knfsd is currently down
rpc.nfsd: Writing version string to kernel: -2 -3 +4
rpc.nfsd: Created AF_INET TCP socket.
{about 2 minutes later}
[ 560.800037] set_max_drc nfsd_drc_max_mem 3948544
{then about 97 seconds later}
rpc.nfsd: Created AF_INET6 TCP socket.
[ 657.120279] nfsd: creating service
[ 657.120286] nfsd: allocating 32 readahead buffers.
[ 657.120376] nfsd4_umh_cltrack_upcall: cmd: init
[ 657.120381] nfsd4_umh_cltrack_upcall: arg: (null)
[ 657.120383] nfsd4_umh_cltrack_upcall: env0:
NFSDCLTRACK_GRACE_START=1472726583
[ 657.120385] nfsd4_umh_cltrack_upcall: env1: (null)
[ 657.151076] NFSD: end of grace period
[ 657.151086] nfsd4_umh_cltrack_upcall: cmd: gracedone
[ 657.151088] nfsd4_umh_cltrack_upcall: arg: 1472726583
[ 657.151090] nfsd4_umh_cltrack_upcall: env0:
NFSDCLTRACK_LEGACY_TOPDIR=/var/lib/nfs/v4recovery
[ 657.151092] nfsd4_umh_cltrack_upcall: env1: (null)
[ 657.153448] nfsd4_umh_cltrack_upcall: /sbin/nfsdcltrack return value: 0
[ 657.153885] nfsd4_umh_cltrack_upcall: /sbin/nfsdcltrack return value: 0
[ 657.153890] NFSD: starting 90-second grace period (net ffffffff818b8a40)
[ 747.359945] NFSD: laundromat service - starting
[ 747.359953] NFSD: laundromat_main - sleeping for 90 seconds
[ 837.599965] NFSD: laundromat service - starting
[ 837.599973] NFSD: laundromat_main - sleeping for 90 seconds
If I reboot and perform the same process, except running "strace
rpc.nfsd --no-udp -N 2 -N 3 8" then I see:
==========
execve("/usr/bin/rpc.nfsd", ["rpc.nfsd", "--no-udp", "-N", "2", "-N",
"3", "8"], [/* 33 vars */]) = 0
brk(NULL) = 0x1609000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=69980, ...}) = 0
mmap(NULL, 69980, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f8548f20000
close(3) = 0
open("/usr/lib/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\260\3\2\0\0\0\0\0"...,
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1951744, ...}) = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x7f8548f1e000
mmap(NULL, 3791152, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3,
0) = 0x7f8548972000
mprotect(0x7f8548b07000, 2093056, PROT_NONE) = 0
mmap(0x7f8548d06000, 24576, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x194000) = 0x7f8548d06000
mmap(0x7f8548d0c000, 14640, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f8548d0c000
close(3) = 0
arch_prctl(ARCH_SET_FS, 0x7f8548f1f440) = 0
mprotect(0x7f8548d06000, 16384, PROT_READ) = 0
mprotect(0x604000, 4096, PROT_READ) = 0
mprotect(0x7f8548f32000, 4096, PROT_READ) = 0
munmap(0x7f8548f20000, 69980) = 0
brk(NULL) = 0x1609000
brk(0x162a000) = 0x162a000
getpid() = 2156
rt_sigaction(SIGUSR1, {0x402b10, [USR1], SA_RESTORER|SA_RESTART,
0x7f85489a50b0}, {SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGUSR2, {0x402b10, [USR2], SA_RESTORER|SA_RESTART,
0x7f85489a50b0}, {SIG_DFL, [], 0}, 8) = 0
chdir("/var/lib/nfs") = 0
stat("/proc/fs/nfsd/threads", {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
open("/proc/fs/nfsd/portlist", O_RDONLY) = 3
read(3,
{{{ about 153 seconds later - yes the read line is split by this time
as shown }}}
"tcp 2049\n", 128) = 9
close(3) = 0
open("/dev/null", O_RDWR) = 3
dup2(3, 0) = 0
dup2(3, 1) = 1
dup2(3, 2) = 2
open("/proc/self/fd", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 4
fstat(4, {st_mode=S_IFDIR|0500, st_size=0, ...}) = 0
getdents(4, /* 7 entries */, 32768) = 168
close(3) = 0
getdents(4, /* 0 entries */, 32768) = 0
close(4) = 0
open("/proc/fs/nfsd/threads", O_WRONLY) = 3
write(3, "8\n", 2
{{{ about 193 seconds later }}}
) = 2
close(3) = 0
exit_group(0) = ?
+++ exited with 0 +++
==========
Now that it's completed, I can cat /proc/fs/nfsd/{portlist,threads} instantly.
But, if I stop nfsd and try restarting it, I get the delay again.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: nfs-server (v4.x only) takes extra 6 minutes to start without rpcbind
2016-09-01 11:22 nfs-server (v4.x only) takes extra 6 minutes to start without rpcbind james harvey
@ 2016-09-02 0:50 ` james harvey
2016-09-03 0:38 ` Steve Dickson
0 siblings, 1 reply; 5+ messages in thread
From: james harvey @ 2016-09-02 0:50 UTC (permalink / raw)
To: Linux NFS Mailing List
[-- Attachment #1: Type: text/plain, Size: 1924 bytes --]
On Thu, Sep 1, 2016 at 7:22 AM, james harvey <jamespharvey20@gmail.com> wrote:
> Up to date Arch. Kernel 4.7.2 (-1 Arch). nfs-utils 1.3.4 (-1 Arch).
> No firewall running on this system.
>
> I started writing that an nfs-server configured for v4.x only would
> never start if there was no rpcbind, BUT wound up finding out it does
> start, it just takes ~ 6 minutes when with rpcbind it's "instant" /
> less than 1 second.
Replicated on Fedora 24, kernel 4.6.7 (-300.fc24.x86_64), nfs-utils
1.3.4 (-1.rc2.fc24), and rpcbind 0.2.3 (-11.rc1.fc24).
{{{ fresh network iso install, using minimal install selection in
install GUI }}}
# yum install nfs-utils
# systemctl enable nfs-server
# vi /etc/sysconfig/nfs
{{{ RPCNFSDARGS="-N 2 -N 3" \ RPCMOUNTDOPTS="-N 2 -N 3" }}}
{{{ I've tried -N options with and without spaces, as I've seen it both ways }}}
# systemctl reboot
Well, Fedora (as Arch does) starts nfs-server for v4.x just fine with
rpcbind. Fedora fails to start nfs-idmapd with "/usr/sbin/rpc.idmapd:
symbol lookup error: /lib64/libnfsidmap.so.0: undefined symbol:
__dn_expand". nfs-idmapd starts fine on Arch.
Starting to started is "instant" (less than 1 second.)
But, moving on:
# systemctl mask rpcbind.service rpcbind.socket
# systemctl reboot
# systemctl status nfs-server
Sep 01 20:29:00 fedora systemd[1]: Starting NFS server and services...
Sep 01 20:35:22 fedora systemd[1]: Started NFS server and services
Then to strace:
# systemctl disable nfs-server
# systemctl reboot
# systemctl start nfs-config.service
{{{ proc-fs-nfsd.mount and var-lib-nfsd-rpc_pipefs.mount are already active }}}
# systemctl start nfs-idmapd
{{{ still fails with undefined symbol __dn_expand }}}
# rpc.mountd --foreground -N 2 -N 3
{{{ another tty }}}
# strace rpc.nfsd --debug -N 2 -N 3 8
Gives the attached strace output, which shows the same two really long
delays when reading or writing /proc/fs/nfsd/portlist.
[-- Attachment #2: strace.rpc.nfsd --]
[-- Type: application/octet-stream, Size: 11424 bytes --]
execve("/usr/sbin/rpc.nfsd", ["rpc.nfsd", "--debug", "-N", "2", "-N", "3", "8"], [/* 21 vars */]) = 0
brk(NULL) = 0x55c0a983b000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fa82ac64000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=21172, ...}) = 0
mmap(NULL, 21172, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fa82ac5e000
close(3) = 0
open("/lib64/libtirpc.so.3", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0`\204\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=193560, ...}) = 0
mmap(NULL, 2289320, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fa82a813000
mprotect(0x7fa82a840000, 2093056, PROT_NONE) = 0
mmap(0x7fa82aa3f000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2c000) = 0x7fa82aa3f000
close(3) = 0
open("/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0P\10\2\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=2089496, ...}) = 0
mmap(NULL, 3938656, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fa82a451000
mprotect(0x7fa82a60a000, 2093056, PROT_NONE) = 0
mmap(0x7fa82a809000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1b8000) = 0x7fa82a809000
mmap(0x7fa82a80f000, 14688, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fa82a80f000
close(3) = 0
open("/lib64/libgssapi_krb5.so.2", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\320\266\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=320800, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fa82ac5d000
mmap(NULL, 2411200, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fa82a204000
mprotect(0x7fa82a24e000, 2097152, PROT_NONE) = 0
mmap(0x7fa82a44e000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x4a000) = 0x7fa82a44e000
close(3) = 0
open("/lib64/libkrb5.so.3", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\300@\2\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=951440, ...}) = 0
mmap(NULL, 3036352, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fa829f1e000
mprotect(0x7fa829ff3000, 2097152, PROT_NONE) = 0
mmap(0x7fa82a1f3000, 69632, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xd5000) = 0x7fa82a1f3000
close(3) = 0
open("/lib64/libk5crypto.so.3", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0pC\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=201424, ...}) = 0
mmap(NULL, 2297624, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fa829ced000
mprotect(0x7fa829d1c000, 2093056, PROT_NONE) = 0
mmap(0x7fa829f1b000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2e000) = 0x7fa829f1b000
close(3) = 0
open("/lib64/libcom_err.so.2", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0\24\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=15248, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fa82ac5c000
mmap(NULL, 2109608, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fa829ae9000
mprotect(0x7fa829aec000, 2093056, PROT_NONE) = 0
mmap(0x7fa829ceb000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2000) = 0x7fa829ceb000
close(3) = 0
open("/lib64/libpthread.so.0", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0``\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=142312, ...}) = 0
mmap(NULL, 2208808, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fa8298cd000
mprotect(0x7fa8298e4000, 2093056, PROT_NONE) = 0
mmap(0x7fa829ae3000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x16000) = 0x7fa829ae3000
mmap(0x7fa829ae5000, 13352, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fa829ae5000
close(3) = 0
open("/lib64/libkrb5support.so.0", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0`2\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=61248, ...}) = 0
mmap(NULL, 2155208, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fa8296be000
mprotect(0x7fa8296cb000, 2097152, PROT_NONE) = 0
mmap(0x7fa8298cb000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xd000) = 0x7fa8298cb000
close(3) = 0
open("/lib64/libdl.so.2", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240\r\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=19736, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fa82ac5b000
mmap(NULL, 2109680, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fa8294ba000
mprotect(0x7fa8294bd000, 2093056, PROT_NONE) = 0
mmap(0x7fa8296bc000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2000) = 0x7fa8296bc000
close(3) = 0
open("/lib64/libkeyutils.so.1", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0P\24\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=15128, ...}) = 0
mmap(NULL, 2109448, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fa8292b6000
mprotect(0x7fa8292b9000, 2093056, PROT_NONE) = 0
mmap(0x7fa8294b8000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2000) = 0x7fa8294b8000
mmap(0x7fa8294b9000, 8, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fa8294b9000
close(3) = 0
open("/lib64/libresolv.so.2", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0009\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=110136, ...}) = 0
mmap(NULL, 2202184, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fa82909c000
mprotect(0x7fa8290b3000, 2093056, PROT_NONE) = 0
mmap(0x7fa8292b2000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x16000) = 0x7fa8292b2000
mmap(0x7fa8292b4000, 6728, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fa8292b4000
close(3) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fa82ac5a000
open("/lib64/libselinux.so.1", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\320c\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=153192, ...}) = 0
mmap(NULL, 2253680, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fa828e75000
mprotect(0x7fa828e98000, 2097152, PROT_NONE) = 0
mmap(0x7fa829098000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x23000) = 0x7fa829098000
mmap(0x7fa82909a000, 4976, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fa82909a000
close(3) = 0
open("/lib64/libpcre.so.1", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\300\25\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=471568, ...}) = 0
mmap(NULL, 2564360, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fa828c02000
mprotect(0x7fa828c74000, 2093056, PROT_NONE) = 0
mmap(0x7fa828e73000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x71000) = 0x7fa828e73000
close(3) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fa82ac59000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fa82ac58000
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fa82ac56000
arch_prctl(ARCH_SET_FS, 0x7fa82ac56800) = 0
mprotect(0x7fa82a809000, 16384, PROT_READ) = 0
mprotect(0x7fa829ae3000, 4096, PROT_READ) = 0
mprotect(0x7fa828e73000, 4096, PROT_READ) = 0
mprotect(0x7fa8296bc000, 4096, PROT_READ) = 0
mprotect(0x7fa829098000, 4096, PROT_READ) = 0
mprotect(0x7fa8292b2000, 4096, PROT_READ) = 0
mprotect(0x7fa8294b8000, 4096, PROT_READ) = 0
mprotect(0x7fa8298cb000, 4096, PROT_READ) = 0
mprotect(0x7fa829ceb000, 4096, PROT_READ) = 0
mprotect(0x7fa829f1b000, 8192, PROT_READ) = 0
mprotect(0x7fa82a1f3000, 61440, PROT_READ) = 0
mprotect(0x7fa82a44e000, 8192, PROT_READ) = 0
mprotect(0x7fa82aa3f000, 8192, PROT_READ) = 0
mprotect(0x55c0a813a000, 4096, PROT_READ) = 0
mprotect(0x7fa82ac65000, 4096, PROT_READ) = 0
munmap(0x7fa82ac5e000, 21172) = 0
set_tid_address(0x7fa82ac56ad0) = 1050
set_robust_list(0x7fa82ac56ae0, 24) = 0
rt_sigaction(SIGRTMIN, {0x7fa8298d2b00, [], SA_RESTORER|SA_SIGINFO, 0x7fa8298ddc30}, NULL, 8) = 0
rt_sigaction(SIGRT_1, {0x7fa8298d2b90, [], SA_RESTORER|SA_RESTART|SA_SIGINFO, 0x7fa8298ddc30}, NULL, 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0
getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM64_INFINITY}) = 0
statfs("/sys/fs/selinux", {f_type=SELINUX_MAGIC, f_bsize=4096, f_blocks=0, f_bfree=0, f_bavail=0, f_files=0, f_ffree=0, f_fsid={0, 0}, f_namelen=255, f_frsize=4096, f_flags=ST_VALID|ST_RELATIME}) = 0
statfs("/sys/fs/selinux", {f_type=SELINUX_MAGIC, f_bsize=4096, f_blocks=0, f_bfree=0, f_bavail=0, f_files=0, f_ffree=0, f_fsid={0, 0}, f_namelen=255, f_frsize=4096, f_flags=ST_VALID|ST_RELATIME}) = 0
brk(NULL) = 0x55c0a983b000
brk(0x55c0a985c000) = 0x55c0a985c000
access("/etc/selinux/config", F_OK) = 0
rt_sigaction(SIGUSR1, {0x55c0a7f39090, [USR1], SA_RESTORER|SA_RESTART, 0x7fa82a485770}, {SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGUSR2, {0x55c0a7f39090, [USR2], SA_RESTORER|SA_RESTART, 0x7fa82a485770}, {SIG_DFL, [], 0}, 8) = 0
chdir("/var/lib/nfs") = 0
stat("/proc/fs/nfsd/threads", {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
open("/proc/fs/nfsd/portlist", O_RDONLY) = 3
read(3,
{{{ about 153 seconds later - yes the read line is split by this time as shown }}}
"tcp 2049\n", 128) = 9
close(3) = 0
write(2, "rpc.nfsd: ", 10rpc.nfsd: ) = 10
write(2, "knfsd is currently up", 21knfsd is currently up) = 21
write(2, "\n", 1
) = 1
open("/dev/null", O_RDWR) = 3
dup2(3, 0) = 0
dup2(3, 1) = 1
dup2(3, 2) = 2
open("/proc/self/fd", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 4
fstat(4, {st_mode=S_IFDIR|0500, st_size=0, ...}) = 0
getdents(4, /* 7 entries */, 32768) = 168
close(3) = 0
getdents(4, /* 0 entries */, 32768) = 0
close(4) = 0
open("/proc/fs/nfsd/threads", O_WRONLY) = 3
write(3, "8\n", 2
{{{ about 193 seconds later }}}
) = 2
close(3) = 0
exit_group(0) = ?
+++ exited with 0 +++
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: nfs-server (v4.x only) takes extra 6 minutes to start without rpcbind
2016-09-02 0:50 ` james harvey
@ 2016-09-03 0:38 ` Steve Dickson
2016-09-03 2:55 ` james harvey
0 siblings, 1 reply; 5+ messages in thread
From: Steve Dickson @ 2016-09-03 0:38 UTC (permalink / raw)
To: james harvey, Linux NFS Mailing List
Hello,
On 09/01/2016 08:50 PM, james harvey wrote:
> On Thu, Sep 1, 2016 at 7:22 AM, james harvey <jamespharvey20@gmail.com> wrote:
>> Up to date Arch. Kernel 4.7.2 (-1 Arch). nfs-utils 1.3.4 (-1 Arch).
>> No firewall running on this system.
>>
>> I started writing that an nfs-server configured for v4.x only would
>> never start if there was no rpcbind, BUT wound up finding out it does
>> start, it just takes ~ 6 minutes when with rpcbind it's "instant" /
>> less than 1 second.
>
> Replicated on Fedora 24, kernel 4.6.7 (-300.fc24.x86_64), nfs-utils
> 1.3.4 (-1.rc2.fc24), and rpcbind 0.2.3 (-11.rc1.fc24).
>
> {{{ fresh network iso install, using minimal install selection in
> install GUI }}}
> # yum install nfs-utils
> # systemctl enable nfs-server
> # vi /etc/sysconfig/nfs
> {{{ RPCNFSDARGS="-N 2 -N 3" \ RPCMOUNTDOPTS="-N 2 -N 3" }}}
> {{{ I've tried -N options with and without spaces, as I've seen it both ways }}}
> # systemctl reboot
>
> Well, Fedora (as Arch does) starts nfs-server for v4.x just fine with
> rpcbind. Fedora fails to start nfs-idmapd with "/usr/sbin/rpc.idmapd:
> symbol lookup error: /lib64/libnfsidmap.so.0: undefined symbol:
> __dn_expand". nfs-idmapd starts fine on Arch.
This has been fixed by https://bodhi.fedoraproject.org/updates/FEDORA-2016-625bd99661
>
> Starting to started is "instant" (less than 1 second.)
>
>
> But, moving on:
> # systemctl mask rpcbind.service rpcbind.socket
> # systemctl reboot
There has been problems with systemd starting the listening
socket... I wonder if this is yea another one...
>
> # systemctl status nfs-server
> Sep 01 20:29:00 fedora systemd[1]: Starting NFS server and services...
> Sep 01 20:35:22 fedora systemd[1]: Started NFS server and services
>
>
> Then to strace:
> # systemctl disable nfs-server
> # systemctl reboot
> # systemctl start nfs-config.service
> {{{ proc-fs-nfsd.mount and var-lib-nfsd-rpc_pipefs.mount are already active }}}
> # systemctl start nfs-idmapd
> {{{ still fails with undefined symbol __dn_expand }}}
Again this has been fixed...
>
> # rpc.mountd --foreground -N 2 -N 3
>
> {{{ another tty }}}
> # strace rpc.nfsd --debug -N 2 -N 3 8
>
> Gives the attached strace output, which shows the same two really long
> delays when reading or writing /proc/fs/nfsd/portlist.
>
I don't see the attachment...
steved.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: nfs-server (v4.x only) takes extra 6 minutes to start without rpcbind
2016-09-03 0:38 ` Steve Dickson
@ 2016-09-03 2:55 ` james harvey
2016-10-12 6:25 ` NeilBrown
0 siblings, 1 reply; 5+ messages in thread
From: james harvey @ 2016-09-03 2:55 UTC (permalink / raw)
To: Steve Dickson; +Cc: Linux NFS Mailing List
On Fri, Sep 2, 2016 at 8:38 PM, Steve Dickson <SteveD@redhat.com> wrote:
> On 09/01/2016 08:50 PM, james harvey wrote:
>> On Thu, Sep 1, 2016 at 7:22 AM, james harvey <jamespharvey20@gmail.com> wrote:
>>> Up to date Arch. Kernel 4.7.2 (-1 Arch). nfs-utils 1.3.4 (-1 Arch).
>>> No firewall running on this system.
>>>
>>> I started writing that an nfs-server configured for v4.x only would
>>> never start if there was no rpcbind, BUT wound up finding out it does
>>> start, it just takes ~ 6 minutes when with rpcbind it's "instant" /
>>> less than 1 second.
>>
>> Replicated on Fedora 24, kernel 4.6.7 (-300.fc24.x86_64), nfs-utils
>> 1.3.4 (-1.rc2.fc24), and rpcbind 0.2.3 (-11.rc1.fc24).
>>
>> {{{ fresh network iso install, using minimal install selection in
>> install GUI }}}
>> # yum install nfs-utils
>> # systemctl enable nfs-server
>> # vi /etc/sysconfig/nfs
>> {{{ RPCNFSDARGS="-N 2 -N 3" \ RPCMOUNTDOPTS="-N 2 -N 3" }}}
>> {{{ I've tried -N options with and without spaces, as I've seen it both ways }}}
>> # systemctl reboot
>>
>> Well, Fedora (as Arch does) starts nfs-server for v4.x just fine with
>> rpcbind. Fedora fails to start nfs-idmapd with "/usr/sbin/rpc.idmapd:
>> symbol lookup error: /lib64/libnfsidmap.so.0: undefined symbol:
>> __dn_expand". nfs-idmapd starts fine on Arch.
> This has been fixed by https://bodhi.fedoraproject.org/updates/FEDORA-2016-625bd99661
>
>>
>> Starting to started is "instant" (less than 1 second.)
>>
>>
>> But, moving on:
>> # systemctl mask rpcbind.service rpcbind.socket
>> # systemctl reboot
> There has been problems with systemd starting the listening
> socket... I wonder if this is yea another one...
FWIW, after nfs-server eventually starts, systemctl still shows
rpcbind.socket (and rpcbind.service) as masked, inactive, and dead.
Also /var/run/rpcbind.sock doesn't exist.
I disabled all related services, and rebooted with systemd debugging.
(Disabled them so they could be manually started with boot noise off
on its own.)
dmesg (with all the systemd debugging output) only mentions rpcbind
along with saying "Cannot add dependency job, ignoring: Unit
rpcbind.socket is masked." Not looking to me like it's trying to
start it.
I'm not familiar with how the proc fs is handled internally. IF this
were in the sys fs, which I am more familiar with, I would be thinking
whichever kernel module provided the show and store functions for
.../nfsd/portlist is taking a really long time to execute when it
can't connect to rpcbind.
This didn't wind up helping here, but turning on systemd debugging
showed me rpc-statd.service was trying to be started (as
nfs-server.service Wants it.) Although masking rpc-statd.service
certainly prevents it from starting, it doesn't eliminate the long
delay.
The relevant part of the 6MB dmesg is:
==========
[ 98.158892] systemd[1]: Mounted NFSD configuration filesystem.
[ 98.161917] systemd[1]: Mounted RPC Pipe File System.
[ 98.172261] systemd[1]: Starting Preprocess NFS configuration...
[ 98.184153] systemd[1]: Started Preprocess NFS configuration.
[ 98.185463] systemd[1]: Started NFS Mount Daemon.
[ 98.187190] systemd[1]: Starting NFSv4 ID-name mapping service...
[ 98.190856] systemd[1]: nfs-idmapd.service: Control process exited,
code=exited status=127
[ 98.191561] systemd[1]: Failed to start NFSv4 ID-name mapping service.
[ 98.192050] systemd[1]: nfs-idmapd.service: Unit entered failed state.
[ 98.192813] systemd[1]: nfs-idmapd.service: Failed with result 'exit-code'.
[ 393.992248] NFSD: starting 90-second grace period (net ffffffff81cfb7c0)
[ 393.996640] systemd[1]: Received SIGCHLD from PID 788 (rpc.nfsd).
[ 393.997043] systemd[1]: Child 788 (rpc.nfsd) died (code=exited,
status=0/SUCCESS)
[ 393.997095] systemd[1]: nfs-server.service: Child 788 belongs to
nfs-server.service
[ 393.997110] systemd[1]: nfs-server.service: Main process exited,
code=exited, status=0/SUCCESS
[ 393.997444] systemd[1]: nfs-server.service: Changed start -> exited
[ 393.997454] systemd[1]: nfs-server.service: Job
nfs-server.service/start finished, result=done
[ 393.997466] systemd[1]: Started NFS server and services.
[ 394.009311] systemd[1]: Starting Notify NFS peers of a restart...
[ 394.031645] systemd[1]: Started Notify NFS peers of a restart.
==========
>> # systemctl status nfs-server
>> Sep 01 20:29:00 fedora systemd[1]: Starting NFS server and services...
>> Sep 01 20:35:22 fedora systemd[1]: Started NFS server and services
>>
>>
>> Then to strace:
>> # systemctl disable nfs-server
>> # systemctl reboot
>> # systemctl start nfs-config.service
>> {{{ proc-fs-nfsd.mount and var-lib-nfsd-rpc_pipefs.mount are already active }}}
>> # systemctl start nfs-idmapd
>> {{{ still fails with undefined symbol __dn_expand }}}
> Again this has been fixed...
>
>>
>> # rpc.mountd --foreground -N 2 -N 3
>>
>> {{{ another tty }}}
>> # strace rpc.nfsd --debug -N 2 -N 3 8
>>
>> Gives the attached strace output, which shows the same two really long
>> delays when reading or writing /proc/fs/nfsd/portlist.
>>
> I don't see the attachment...
>
> steved.
Strange, wonder if the list removed it - I do see it on my sent message.
Anyways, I just uploaded it here: http://pastebin.ca/3709748
The delays happen at lines 145-149, which print as one line, I just
broke it apart showing the characters that show on the line before and
after the delay.
Same at lines 166-170.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: nfs-server (v4.x only) takes extra 6 minutes to start without rpcbind
2016-09-03 2:55 ` james harvey
@ 2016-10-12 6:25 ` NeilBrown
0 siblings, 0 replies; 5+ messages in thread
From: NeilBrown @ 2016-10-12 6:25 UTC (permalink / raw)
To: james harvey, Steve Dickson; +Cc: Linux NFS Mailing List
[-- Attachment #1: Type: text/plain, Size: 1632 bytes --]
On Sat, Sep 03 2016, james harvey wrote:
>
> FWIW, after nfs-server eventually starts, systemctl still shows
> rpcbind.socket (and rpcbind.service) as masked, inactive, and dead.
I think this is a kernel bug. You can fix it by reverting
Commit: 4b0ab51db32e ("SUNRPC: xs_sock_mark_closed() does not need to trigger socket autoclose")
See also http://www.spinics.net/lists/linux-nfs/msg59264.html and
follow-ups.
>>>
>>> # rpc.mountd --foreground -N 2 -N 3
>>>
>>> {{{ another tty }}}
>>> # strace rpc.nfsd --debug -N 2 -N 3 8
>>>
>>> Gives the attached strace output, which shows the same two really long
>>> delays when reading or writing /proc/fs/nfsd/portlist.
>>>
>> I don't see the attachment...
>>
>> steved.
>
> Strange, wonder if the list removed it - I do see it on my sent message.
>
> Anyways, I just uploaded it here: http://pastebin.ca/3709748
>
> The delays happen at lines 145-149, which print as one line, I just
> broke it apart showing the characters that show on the line before and
> after the delay.
The delay at 'read' is waiting for nfsd_mutex. Probably something else
was trying to start up nfsd and hit the 3 minute wait while writing the
threads. Maybe you interrupted that or backgrounded it or something.
>
> Same at lines 166-170.
This one is the real problem. Starting nfsd tries to register with
rpcbind (even for v4-only) and (due to the bug) it takes 3 minutes to
timeout.
NeilBrown
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 800 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2016-10-12 6:43 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-09-01 11:22 nfs-server (v4.x only) takes extra 6 minutes to start without rpcbind james harvey
2016-09-02 0:50 ` james harvey
2016-09-03 0:38 ` Steve Dickson
2016-09-03 2:55 ` james harvey
2016-10-12 6:25 ` NeilBrown
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).