On Tue, Dec 27 2016, daggs wrote:
> Greetings Neil,
>
>> On Mon, Dec 26 2016, daggs wrote:
>>
>> > Greetings,
>> >
>> >> On Mon, Dec 26 2016, daggs wrote:
>> >>
>> >> >> Can you strace mountd while you attempt a mount?
>> >> >> e.g.
>> >> >> strace -o /tmp/trace -s 1000 -p 241
>> >> >>
>> >> >> and send the /tmp/trace.
>> >> >> Also, after the attempt fails, run
>> >> >> rpcdebug -m rpc -s cache
>> >> >> grep . /proc/net/rpc/*/c*
>> >> >> cat /proc/fs/nfsd/exports
>> >> >>
>> >> >> and report the output.
>> >> >>
>> >> > here:
>> >> >
>> >> > # cat /tmp/trace
>> >> > pselect6(1024, [3 4 5 7 8 9 10 11 12], NULL, NULL, NULL, NULL) = 1 (in [3])
>> >> > read(3, "nfsd 10.0.0.1\n", 32768) = 14
>> >> > openat(AT_FDCWD, "/run/nfs/etab", O_RDONLY) = 14
>> >> > fstat(14, {st_mode=S_IFREG|0644, st_size=435, ...}) = 0
>> >> > close(14) = 0
>> >> > write(3, "nfsd 10.0.0.1 2079 10.0.0.0/24 \n", 32) = 32
>> >>
>> >> This is weird.
>> >> Here mountd is telling nfsd that when a request comes from IP address
>> >> 10.0.0.1, it should look for export entries associated with the client
>> >> name "10.0.0.0/24", which is good.
>> >> However the expiry time for that information is "2079", which is back in
>> >> January 1970.
>> >> When mountd writes that number, it computes it as
>> >> time(0) + DEFAULT_TTL
>> >> where DEFAULT_TTL is (30 * 60)
>> >> Which suggests time(0) is "279".
>> >>
>> >> What is the current time on this system?
>> >>
>> >> If it really was very early on Jan 1st 1970, it should work, however...
>> >>
>> >>
>> >> > pselect6(1024, [3 4 5 7 8 9 10 11 12], NULL, NULL, NULL, NULL <detached ...>
>> >> > # rpcdebug -m rpc -s cache
>> >> > rpc cache
>> >> > # grep . /proc/net/rpc/*/c*
>> >> > /proc/net/rpc/auth.unix.gid/content:#uid cnt: gids...
>> >> > /proc/net/rpc/auth.unix.ip/channel:nfsd 10.0.0.1
>> >> > /proc/net/rpc/auth.unix.ip/channel:nfsd 10.0.0.1
>> >> > /proc/net/rpc/auth.unix.ip/content:#class IP domain
>> >> > /proc/net/rpc/auth.unix.ip/content:# expiry=2079 refcnt=1 flags=1
>> >> > /proc/net/rpc/auth.unix.ip/content:# nfsd 10.0.0.1 10.0.0.0/24
>> >>
>> >> ...the fact that this line is commented out indicates that the entry in
>> >> the cache is already expired. So the time must be after 2079.
>> >>
>> >> Maybe the time is getting set from the network at an awkward time that
>> >> races with NFS service some how.
>> >> Can you find a way to run "exportfs -f" after the time has been set
>> >> correctly?
>> >>
>> >> NeilBrown
>> >>
>> >>
>> >
>> > wait, I think I've seen this somewhere, does this feature needs rtc? this board doesn't have rtc component.
>> > for example, I cannot use openssh as ssh server because it needs rtc. I have to use dropbear.
>> > if so, this looks like it will affect nfsv3 mounts, am I right?
>>
>> No, you shouldn't need an RTC.
>> You need the synchronize the clock with ntp or similar, else time stamps
>> on files will look wrong.
>> Though I think we fixed issues with wall-clock-time jumping in 2.6.37...
>>
>> If you could try using "exportfs -f", and explain what does happen with
>> time - do you use ntp ?? - we might be able to make progress.
>
> I'll build ntp into the image and try. does this affects nfsv3 too?
Having correct time is quite important for any version of NFS. With out
it, time stamps on files get confused. "make" doesn't cope at all,
"tar" often complains, other tools might experience other problems.
I still cannot quite see why having an incorrect clock would cause the
particular symptoms you are experiencing, but it is worth fixing anyway.
>
> what should I do with the "exportfs -f"? jsut run it and retry?
Yes.
NeilBrown
>
> Thanks,
>
> Dagg.
Attachment:
signature.asc
Description: PGP signature
