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
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
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
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.
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
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
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
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
> 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
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:
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
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.
12 matches
Mail list logo