Re: NFS server down, again, and again, and again...

2018-04-20 Thread Rupert Gallagher
Update... The command "doas mountd -d" enters debug mode and displays its normal updates as clients mount the share. This is what I observed on a controlled environment of three "windows 10 pro" clients. The server had a single share: /path/to/folder -network 192.168.1 -mask 255.255.255.0

Re: NFS server down, again, and again, and again...

2018-04-19 Thread Fred
On 04/19/18 16:39, Steve Williams wrote: On 19/04/2018 7:55 AM, Rupert Gallagher wrote: On Thu, Apr 19, 2018 at 15:38, Zé Loff wrote: # mountd -d > /var/log/mountd.log 2&>1 & It is the first thing I did this morning. Unfortunately it does not survive when ssh breaks

Re: NFS server down, again, and again, and again...

2018-04-19 Thread Steve Williams
On 19/04/2018 7:55 AM, Rupert Gallagher wrote: On Thu, Apr 19, 2018 at 15:38, Zé Loff wrote: # mountd -d > /var/log/mountd.log 2&>1 & It is the first thing I did this morning. Unfortunately it does not survive when ssh breaks out. Also, mountd -d is returning the shell

Re: NFS server down, again, and again, and again...

2018-04-19 Thread Rupert Gallagher
On Thu, Apr 19, 2018 at 15:38, Zé Loff wrote: > # mountd -d > /var/log/mountd.log 2&>1 & It is the first thing I did this morning. Unfortunately it does not survive when ssh breaks out. Also, mountd -d is returning the shell prompt again, so I have no logs at all.

Re: NFS server down, again, and again, and again...

2018-04-19 Thread Rupert Gallagher
On 18 April 2018 8:04 PM, Ryan Freeman wrote: > This is how it works when your system is normal: Unfortunately my system was not "normal", because mountd -d returned the shell prompt, as I said. I also said that mountd_flags=-d prevents the OS from restarting. I had to

Re: NFS server down, again, and again, and again...

2018-04-19 Thread Rupert Gallagher
On 18 April 2018 8:04 PM, Ryan Freeman wrote: >> On this point, ``rcctl restart mountd'' works fine. Restarting mountd >> will not harm things already mounted, they will already be handled >> by one of the running nfsd processes. It does not work fine at all. This is what I

Re: NFS server down, again, and again, and again...

2018-04-18 Thread Ryan Freeman
On Wed, Apr 18, 2018 at 01:08:01PM -0400, Rupert Gallagher wrote: > This is all I managed to retrieve from the logs (/var/log/daemons, > /var/log/messages): > > Mar 12 09:27:20 server mountd[50607]: Socket disconnected > Mar 29 18:05:30 server mountd[52162]: Socket disconnected > Apr 16 12:04:07

Re: NFS server down, again, and again, and again...

2018-04-18 Thread Rupert Gallagher
This is all I managed to retrieve from the logs (/var/log/daemons, /var/log/messages): Mar 12 09:27:20 server mountd[50607]: Socket disconnected Mar 29 18:05:30 server mountd[52162]: Socket disconnected Apr 16 12:04:07 server mountd[66430]: Socket disconnected Apr 17 17:55:26 server

Re: NFS server down, again, and again, and again...

2018-04-17 Thread Rupert Gallagher
> Do you mean nfsd server dies? I mean the NFS service as delivered by nfsd, portmap and mountd. > Does it provide core dump? No! > You do not need to restart it manually: just create script that checks for server existence (like ``/etc/rc.d/nfsd check``) and run it if it is dead. I usually

Re: NFS server down, again, and again, and again...

2018-04-17 Thread IL Ka
You could use ktrace(1) to trace all calls and then use kdump(1) to read them, and may help you to find what cause it to die, but it may be tricky for anyone except nfsd developer.. You can also try to find person who supports it by looking at last commits to:

Re: NFS server down, again, and again, and again...

2018-04-17 Thread IL Ka
Do you mean nfsd server dies? Does it provide core dump? You do not need to restart it manually: just create script that checks for server existence (like ``/etc/rc.d/nfsd check``) and run it if it is dead. On Wed, Apr 18, 2018 at 12:00 AM, Rupert Gallagher wrote: > The

NFS server down, again, and again, and again...

2018-04-17 Thread Rupert Gallagher
The crash usually occurs in the morning, when the 'windows 10 pro' clients are powered up. The obsd nfs server must be restarted manually, and the clients are happy again. No error messages, clear logs, and yet it crashes. A mistery.