I've often had difficulty getting the array stopped, today is no exception.

 

I've got a bunch of dockers running, but I stopped them all before attempting to stop the array.

I had a Windows Explorer window open to the array, but I closed it.

I had uTorrent running, but I exited it (not just minimized to the tool tray).

Kodi was in screen-saver mode pulling pictures from the array, but I woke it up to stop the screen saver. (No video playing).

 

I've got 2 telnet sessions running connected to the server. Shortly after clicking "Stop", this appeared in each telnet session:

root@NAS:~#
Message from syslogd@NAS at Oct 30 13:09:06 ...
kernel:unregister_netdevice: waiting for lo to become free. Usage count = 1

At the telnet session, I've copied the /var/log/syslog to /boot, but I can't access it from my Win10 machine - the shares aren't available.

 

The WebGUI is filled with this:

unmounting disk share(s)...Unmounting disks...Retry unmounting disk share(s)...Unmounting disks...Retry unmounting disk share(s)...

and is totally unresponsive.

 

A) What do I do to get the system responding again? In the past, I've simply gone to a telnet session and typed powerdown -reboot which seems like a brutal way of doing it. (I know it does a clean power down, but all I'm trying to do is stop the array, not reboot the server.)

B) What is causing this problem and how do I prevent it in the future?

The unregister_netdevice is a harmless message and doesn't affect anything.

 

One possibility for the continual unmounting of disks is that the other telnet session you had open was using a folder under /mnt/user which would stop the unmounting.

Good to know the unregister_netdevice is nothing to worry about, though I don't remember seeing it prior to a week or so ago.

 

Both telnet sessions were sitting at a command prompt.

 

With the exception of shutting down dockers (which is new to me in the last couple of months since my update from 5.x to 6.x), I've always taken care to shut down everything I can think of that may have access to a file. I took a look at dlandon's Open Files plugin before trying to stop the array, and it said that only smbd had files open and the footnote indicates that shouldn't impact shutdown. Should I use that plugin to kill all open smbd processes prior to stopping the array?

 

I am planning on several start/stops as I migrate all my disks to xfs, and I'd hate to have to powerdown in between them all.

 

I'm attaching the syslog I grabbed, just in case that may provide additional insight. I would have run the full diagnostics, but I forgot that it could be done from the command line, and the GUI was frozen, so...

syslog.2016.10.30.txt.zip

Both telnet sessions were sitting at a command prompt.

 

But what is the current working directory of each telnet session?

 

Both telnet sessions were sitting at a command prompt.

 

But what is the current working directory of each telnet session?

 

 

Ah, that I cannot tell you. Makes sense, though. Both were probably pointed at /mnt/diskx since I'm in the midst of a Reiserfs -> xfs update. Is that enough to keep the device from unmounting?

 

Both telnet sessions were sitting at a command prompt.

 

But what is the current working directory of each telnet session?

 

 

Ah, that I cannot tell you. Makes sense, though. Both were probably pointed at /mnt/diskx since I'm in the midst of a Reiserfs -> xfs update. Is that enough to keep the device from unmounting?

Yes

Geez... I wonder how many times I've typed "powerdown" in a telnet session with the prompt at /mnt/something because it wouldn't unmount drives because my telnet prompt was sitting there...

 

Guess I should have asked a while ago.

 

thanks.