Unassigned Devices - Managing Disk Drives and Remote Shares Outside of The Unraid Array


Recommended Posts

2 minutes ago, CaryV said:

Mustava asked a VERY valid question that was never responded to...

What does it take to either Restart or Terminate unAssigned Devices?  (This plug-in can HANG the system!)  As if that isn't bad enough, the end result is a COLD REBOOT with resultant unclean shutdown and a parity check (for HOURS) upon restarting.

CANNOT Stop the unRaid array or use Shutdown or Reboot - TOTALLY UNRESPONSIVE DUE TO UNASSIGNED DEVICES BEING HUNG!

(Indicated by the 'wavy lines' running perpetually in the "unAssigned Devices section without ever resolving - EVERYTHING else still works; unRaid, Dockers, etc.  Just NO unAssigned Devices)

Scenario starts when one of the unAssigned Devices has an issue; i.e. Had a USB drive connected and shared on secondary system. It stopped running (for whatever reason) and the SMB share to it from the 'primary' system stopped being operational, CAUSING unAssigned Devices to HANG (revealed upon navigating to the unRaid Main page to inspect the device, but unAssigned Devices would no longer respond) AND as mentioned, could not stop the array, reboot, or shutdown the system.  Not without have to "pull the plug" altogether... NOT A GOOD SCENARIO.

So, what does it take to terminate or restart the program (similar to restarting a Docker app) OR avoid unAssigned Devices from hanging in the first place?

 

I really don't appreciate the capitalization emphasis - it appears you are yelling.  You don't need to come across with that kind of attitude to get help with your problem.  I volunteer my time in maintaining UD, and I respond the best I can to all requests.  I appreciate it can be frustrating when things don't work as you'd like.  It's frustrating trying to help every one with an issue when I can't reproduce the issue and users don't post diagnostics so I can try to find the problem.  I need diagnostics to help you.

 

UD can not be restarted.  Just restarting UD, if it was possible is a terrible solution.  Let's find out why it "hangs" and fix that.  UD is a GUI that displays information about unassigned devices, and mounts/unmounts disk drives.  UD has been known to "hang" in the past when there were issues with getting device information.  The worst are CIFS devices (NFS and SMB remote mounted devices).  When they are off-line, the 'df' command hangs and will not terminate, even with an error.  Even 'df' commands on hard drives will hang if the remote CIFS mount is included and off-line.  I've had to limit the 'df' commands to specific devices and not use the generic 'df' on all devices.  Time outs have been implemented on all device operations that can potentially "hang".  That's the best I can do because I did not write the 'df' command.

 

If you have the preclear plugin installed, please remove it.  Preclear also works with unassigned disks in the background and it can sometimes cause a hang when UD is also trying to work with the unassigned devices.

 

CIFS mounts are dependent on solid network operation.  Do not use Jumbo frames.  If you are, change back to the default MTU values in all NICs, switches, router, etc.

 

If you continue to have problems, post your diagnostics.

 

Please don't come across as yelling.  It doesn't inspire me to help you, and will actually annoy me enough so I won't be interested in helping you.

Link to comment

dlandon,

In an effort to try to 'pin down' the issue, here is the precise sequence of events:

Was working in Krusader with the unAssigned device through a SMB share
(and with a local drive in the unRaid array that should have had the "same" contents, rebuilt).

The 'contents' of the unAssigned device "disappeared" (in Krusader)

Used 'telnet' to look at the drive (USB) attached to the 'source' system -
directory system of the drive was prefaced with a number of ???????
and any attempt to navigate within that system was met with an I/O error

(Yes, it truly was offline - went South for no discernable reason, having been used
in its configuration for a number of hours without issue.)

Reason for this is a matter of conjecture, based on what occurred subsequently,
but believe it was due to operation of unRaid (on its own, without user action),
whereby it was taken 'offline'.  (see indication* below)

Attempting to look at the SMB device in unAttached Devices (Main page of unRaid)
only showed the 'continuous wavy line' displayed that never resolved in order to show
the unAssigned devices - which would be 4 SMB mounted devices; two to the 'source' system's
unRaid array (one of which had been mounted), one to a SSD (unAssigned device on the
'source' system, and one to the USB attached hard-drive, once again, attached to the
'source' system as an unAssigned device and utilized through a SMB share on the 'object' system.
(Source system = secondary unRaid server with an array (of four drives), a SSD (unAssigned and shared), and a USB hard drive (unAssigned and shared; the device in question)

An inspection of the 'source' system showed that, yes indeed, the USB hard drive had gone 'offline' and was no longer "mounted" (although the drive itself was not an issue and was still running; the indication*  was that the drive had been taken 'offline' by unRaid).
This indication came about when it was attempted to bring the drive back online in order to resolve the issue at the 'object' system (issue of unAssigned Devices not responding on the 'object' system):

Selected "mount" of the drive which failed.
Stopped all Dockers as well as the unRaid array - it was at that time that the "indication" appeared as at the bottom of the 'page'; an admonishment that there were "too many" (mass storage) devices attached (for current licensing); although, according to unRaid specs, the USB hard-drive should NOT have been counted...
Nonetheless, as the USB drive would not mount (remount) whether the Dockers were stopped, array was stopped, or drive itself was powered off and on, it was time to reboot (source system).

Note: Interestingly enough, unRaid displayed a notification of the drive's condition (errors from SMART; reallocated sectors and reported uncorrect) upon its being power cycled, yet, would still not mount the drive.

After rebooting and restarting the unRaid array as well as the Dockers (apps), reattached the USB drive, mounted and shared - all running as before; however unAssigned Devices on the 'object' system was still "hung".  That's when the unRaid array was attempted to be 'stopped', but did not respond; nor was it possible (many minutes later) to Power down or to Reboot the system (softly).  Subsequently, depressed the power switch (briefly) which showed that the system was attempting shutdown with its "waiting 90 seconds" for a clean shutdown that never happened.
Hung big-time and had to perform a cold reboot.

And, that's the best that I can tell you.  Hope it is of benefit in finding a resolution.
The indication is that the event was triggered by unRaid when the drive went 'offline' and that
unAssigned Devices suffered from the event in the environment in which it was operating.

I understand what you said about the device attachments and the way communication takes place using the SMB shares; as well as the fact the calls are made to OS commands.  Commands of which you have no control in their operation...
Best bet seems to be to have unAssigned devices attempt to circumvent the issue when a device being utilized in unAttached Devices goes offline, so that the 'offending' call is not made in relation to the utilized resource (unAttached device, SMB share).
(Sounds like this has attempted to be done through the limit on 'df' calls and use of time-outs.)

As far as diagnostics are concerned, I presume those would have to be (have been) collected at the time of occurrence.  You are speaking of unRaid diagnostics, correct?  My understanding is that once an unRaid system is rebooted (which both have been at this time), the diagnostics of the condition(s) in question are lost.

Anything else that I can do to provide information, let me know.
Cary
 

Link to comment

Didn't think I'd run across this again, at least not so soon (but I did) and here are the log files from both of the unRaid systems involved;

"headless" file is from the 'source' system that has the USB drive physically attached - the one that went 'offline' (again) and precipitates the problem.

"Tower" file is from the 'object' system that uses a SMB share to access the USB drive (and other SMB shares from the 'source' system).

Tower is the system that has unAssigned Devices hanging - which it is again.

I have to leave the system running in this condition until other operations complete, then I can try whatever you suggest to remedy the situation.

(We already know that in the alternative, I'll have to "pull the plug" on the system.)

I have added highlighting to pertinent portions of the logs as well as some operational notes that may be of benefit.

Thanks,

Cary

 

unAssigned_Hang (3) log_headless.rtf unAssigned_Hang (4) log_tower.rtf

Link to comment
2 hours ago, CaryV said:

Didn't think I'd run across this again, at least not so soon (but I did) and here are the log files from both of the unRaid systems involved;

"headless" file is from the 'source' system that has the USB drive physically attached - the one that went 'offline' (again) and precipitates the problem.

"Tower" file is from the 'object' system that uses a SMB share to access the USB drive (and other SMB shares from the 'source' system).

Tower is the system that has unAssigned Devices hanging - which it is again.

I have to leave the system running in this condition until other operations complete, then I can try whatever you suggest to remedy the situation.

(We already know that in the alternative, I'll have to "pull the plug" on the system.)

I have added highlighting to pertinent portions of the logs as well as some operational notes that may be of benefit.

Thanks,

Cary

 

unAssigned_Hang (3) log_headless.rtf 4.84 kB · 2 downloads unAssigned_Hang (4) log_tower.rtf 5.84 kB · 1 download

You have multiple problems you need to sort out:

Nov 22 00:49:04 Headless kernel: XFS (sdi1): Filesystem has duplicate UUID a2e64706-14cd-44b6-b7b2-e1ec18f0e97e - can't mount
Nov 22 00:49:04 Headless unassigned.devices: Mount of '/dev/sdi1' failed. Error message: mount: /mnt/disks/WCC132184639: wrong fs type, bad option, bad superblock on /dev/sdi1, missing codepage or helper program, or other error.
Nov 22 00:49:31 Headless rc.diskinfo[3938]: SIGHUP received, forcing refresh of disks info.

Looks like preclear is installed.  I've already asked you to remove it.

NOTES
"Filesystem has duplicate UUID" is not exactly true - the whole reason that the drive is mated with this system (as the 'source') is because if it was on the 'object' system IT WOULD have a duplicate UUID, this drive and the one that replaced it on that system.

This is not a UD issue.  You need to sort it out.

Nov 21 20:55:04 Tower kernel: ata14.00: exception Emask 0x32 SAct 0x0 SErr 0x0 action 0xe frozen
Nov 21 20:55:04 Tower kernel: ata14.00: irq_stat 0xffffffff, unknown FIS 00000000 00000000 00000000 00000000, host bus
Nov 21 20:55:04 Tower kernel: ata14.00: failed command: READ DMA EXT
Nov 21 20:55:04 Tower kernel: ata14.00: cmd 25/00:00:20:49:80/00:03:b6:00:00/e0 tag 29 dma 393216 in
Nov 21 20:55:04 Tower kernel: res 50/00:00:1f:4c:80/00:00:b6:00:00/e6 Emask 0x32 (host bus error)
Nov 21 20:55:04 Tower kernel: ata14.00: status: { DRDY }
Nov 21 20:55:04 Tower kernel: ata14: hard resetting link
Nov 21 20:55:05 Tower kernel: ata14: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
Nov 21 20:55:05 Tower kernel: ata14.00: configured for UDMA/133
Nov 21 20:55:05 Tower kernel: ata14: EH complete

You have a cable, controller, or disk problem.

Nov 22 00:10:19 Tower kernel: CIFS VFS: BAD_NETWORK_NAME: \\HEADLESS\OCZ-AGILITY3
Nov 22 00:10:19 Tower kernel: reconnect tcon failed rc = -2

I have no idea what this is about.

 

Reboot your servers and run them for a while then post diagnostics.  Don't go to the UD page until you gather diagnostics.

 

It's better to post information such as log snippets as .txt and not .rtf.

Link to comment
11 minutes ago, dlandon said:

Nov 22 00:49:04 Headless kernel: XFS (sdi1): Filesystem has duplicate UUID a2e64706-14cd-44b6-b7b2-e1ec18f0e97e - can't mount

Duplicate UUID is expected if the drive was replaced on the same system, it can be changed for the unassigned device with:

 

xfs_admin -U generate /dev/sdX1

 

Link to comment

I as well as many other users have remote mounted SMB shares.  I have two to an out of state backup server and have not had any issues with UD hanging.

 

There are some common things I have found with UD hanging:

  • preclear plugin.  The preclear plugin has a background task called rc.diskinfo that gathers information about all UD disks needed to perform preclears.  There have been situations where having the preclear plugin installed causes issues.
  • Using Jumbo frames on a LAN when mounting remote SMB shares.  Jumbo frames are for network experts and require a very particular setup to work properly.  This involves NICs, switches, and routers on the LAN.  Jumbo frames will not add any noticeable performance to your LAN and is not worth the headaches.
  • Remote mounted SMB shares seem to have more issues that NFS.  If possible use NFS as remote mounted shares.

 

5 hours ago, CaryV said:

Best bet seems to be to have unAssigned devices attempt to circumvent the issue when a device being utilized in unAttached Devices goes offline, so that the 'offending' call is not made in relation to the utilized resource (unAttached device, SMB share).
(Sounds like this has attempted to be done through the limit on 'df' calls and use of time-outs.)

UD pings the remote server to see if it is on-line before performing any queries to the remote mounts, and does a lot to try to prevent hanging.  Time outs on commands are only a part of that.  Let's concentrate on troubleshooting your particular situation rather than commenting on my programming skills.

Edited by dlandon
Link to comment
22 hours ago, dlandon said:

There is no file system on the disks, or it is not recognized by UD.

Ah thanks. I didn't realise that you can't just swap drives in and out of the cache pool. I did a new config and reformatted all the non-array drives. Luckily I made a backup of my docker.img and my most-used VM. I'm transferring them back now. Fingers crossed.

Link to comment
7 hours ago, johnnie.black said:

Duplicate UUID is expected if the drive was replaced on the same system, it can be changed for the unassigned device with:

 


xfs_admin -U generate /dev/sdX1

 

Johnnie,

Thanks for that; may need to know this one to change the UUID without resorting to a reformat of drive...

What's interesting is that the drive is NOT in the same system.  It's physically attached to a different system and being utilized by a SMB share setup through unAssigned Devices. (The drive is a shared unAssigned device on another system; other than the one where a drive 'took its place' that DOES have the same UUID.)  I'm not sure why the OS has a problem with this...

 

Link to comment
8 hours ago, dlandon said:

I as well as many other users have remote mounted SMB shares.  I have two to an out of state backup server and have not had any issues with UD hanging.

 

There are some common things I have found with UD hanging:

  • preclear plugin.  The preclear plugin has a background task called rc.diskinfo that gathers information about all UD disks needed to perform preclears.  There have been situations where having the preclear plugin installed causes issues.
  • Using Jumbo frames on a LAN when mounting remote SMB shares.  Jumbo frames are for network experts and require a very particular setup to work properly.  This involves NICs, switches, and routers on the LAN.  Jumbo frames will not add any noticeable performance to your LAN and is not worth the headaches.
  • Remote mounted SMB shares seem to have more issues that NFS.  If possible use NFS as remote mounted shares.

 

UD pings the remote server to see if it is on-line before performing any queries to the remote mounts, and does a lot to try to prevent hanging.  Time outs on commands are only a part of that.  Let's concentrate on troubleshooting your particular situation rather than commenting on my programming skills.

1) Yea, the preclear plug-in is still there; was never a problem before (for months amounting to years), until the USB disk was introduced...

and it didn't come into play UNTIL the USB drive went 'offline' (became unmounted).

If need be, I can remove it for trouble-shooting purposes, but I'm not sure that addresses the issue which will be made clear by what I've perceived to be the sequence of events that triggers the problem...  if the issue can be reproduced, maybe there is a way to resolve.

2) NO Jumbo Frames are in use, just MTU (standard, default)

3) Am using a Windows machine to monitor / administer the two unRaid systems; use of NFS may not be an option in this case.

 

So, as to being able to reproduce the situation which triggers the hanging of UD, this is what appears to transpire.

I attempt to get the USB drive back online by manipulating the 'source' system and while I mentioned that I "unmounted" the SMB share on the 'object' system for the USB drive (when it went 'offline' again), I still had two other SMB shares specified as active (mounted); one to the disk array of the 'source' system; specifically the media content thereof so as to be able to maintain a 'master catalog' on the object system, and another SMB share for a SSD drive so as to include its contents in searches I conduct.

The reason that I mention these connections is because they may well have an impact on the situation, although it did not arise until the introduction of the USB drive, so, to continue.

I was able to view unAssigned devices on the 'object' system AFTER the USB drive went 'offline', hence the statement that I "unmounted" it on the 'object' system (the system where UD hangs vs. the 'source' system where the USB drive is physically attached).

unAssigned Devices did not hang until after I attempted to remount the USB drive (as indicated by the error message that follows) AND subsequently disabled those device(s) on the 'source' system that were being shared and specified as SMB shares (in UD) on the 'object' system.

"Nov 22 00:49:04 Headless unassigned.devices: Mount of '/dev/sdi1' failed. Error message: mount: /mnt/disks/WCC132184639: wrong fs type, bad option, bad superblock on /dev/sdi1, missing codepage or helper program, or other error."

This error does not occur initially; it only appears after the disk had been successfully mounted and in use (for hours) and then goes 'offline'.

We can also now see why it went offline, or more precisely why it was TAKEN offline; as in

"Nov 22 00:49:04 Headless kernel: XFS (sdi1): Filesystem has duplicate UUID a2e64706-14cd-44b6-b7b2-e1ec18f0e97e - can't mount"

As I stated in the notation in the log file (uploaded) this is not exactly true...

The drive WAS mounted to begin with; if it was actually (physically) in a system where there was a UUID conflict, it would not have mounted in the first place.

It is a duplicate UUID only across the network - as to why the OS objects to that, I have no idea; it attempts to extend that uniqueness to other machines and although that is an easy resolve in order to keep it from going offline, it begs the question as to why UD hangs... which is

The termination of the 'sources' of the SMB shares, or more appropriately, the resources being shared, as in

'stopping' them on the 'source' machine triggers the hang with UD on the 'object' machine.

This is what I witnessed when I 'manipulated' the 'source' machine in an attempt to get the USB drive back online (mounted).

Stopping the disk array on that machine disconnects or disassociates the resources with the SMB connection on the 'object' machine.

Disconnects certainly.  Disassociates in that once the array is brought back online, it does not re-establish the (SMB) connection on the 'object' machine; nor could it as UD hung at the point of the disconnection.

(Which is why the following message appeared in the log file; the designation was no longer valid)

"Nov 22 00:10:19 Tower kernel: CIFS VFS: BAD_NETWORK_NAME: \\HEADLESS\OCZ-AGILITY3"

Does this make sense as I've presented it?

Where does that leave us?

Right now, I have a machine with UD hung that I can't stop, shutdown, or reboot (without "pulling the plug").

Anything you want me to try before I do so (and face the impact of an unclean shutdown)?

(All of the 'other' operations that were active before, downloads and parity checking, have concluded at this point.)

Cary

 

Edited by CaryV
Link to comment
2 hours ago, CaryV said:

1) Yea, the preclear plug-in is still there; was never a problem before (for months amounting to years), until the USB disk was introduced...

and it didn't come into play UNTIL the USB drive went 'offline' (became unmounted).

If need be, I can remove it for trouble-shooting purposes, but I'm not sure that addresses the issue which will be made clear by what I've perceived to be the sequence of events that triggers the problem...  if the issue can be reproduced, maybe there is a way to resolve.

2) NO Jumbo Frames are in use, just MTU (standard, default)

3) Am using a Windows machine to monitor / administer the two unRaid systems; use of NFS may not be an option in this case.

 

So, as to being able to reproduce the situation which triggers the hanging of UD, this is what appears to transpire.

I attempt to get the USB drive back online by manipulating the 'source' system and while I mentioned that I "unmounted" the SMB share on the 'object' system for the USB drive (when it went 'offline' again), I still had two other SMB shares specified as active (mounted); one to the disk array of the 'source' system; specifically the media content thereof so as to be able to maintain a 'master catalog' on the object system, and another SMB share for a SSD drive so as to include its contents in searches I conduct.

The reason that I mention these connections is because they may well have an impact on the situation, although it did not arise until the introduction of the USB drive, so, to continue.

I was able to view unAssigned devices on the 'object' system AFTER the USB drive went 'offline', hence the statement that I "unmounted" it on the 'object' system (the system where UD hangs vs. the 'source' system where the USB drive is physically attached).

unAssigned Devices did not hang until after I attempted to remount the USB drive (as indicated by the error message that follows) AND subsequently disabled those device(s) on the 'source' system that were being shared and specified as SMB shares (in UD) on the 'object' system.

"Nov 22 00:49:04 Headless unassigned.devices: Mount of '/dev/sdi1' failed. Error message: mount: /mnt/disks/WCC132184639: wrong fs type, bad option, bad superblock on /dev/sdi1, missing codepage or helper program, or other error."

This error does not occur initially; it only appears after the disk had been successfully mounted and in use (for hours) and then goes 'offline'.

We can also now see why it went offline, or more precisely why it was TAKEN offline; as in

"Nov 22 00:49:04 Headless kernel: XFS (sdi1): Filesystem has duplicate UUID a2e64706-14cd-44b6-b7b2-e1ec18f0e97e - can't mount"

As I stated in the notation in the log file (uploaded) this is not exactly true...

The drive WAS mounted to begin with; if it was actually (physically) in a system where there was a UUID conflict, it would not have mounted in the first place.

It is a duplicate UUID only across the network - as to why the OS objects to that, I have no idea; it attempts to extend that uniqueness to other machines and although that is an easy resolve in order to keep it from going offline, it begs the question as to why UD hangs... which is

The termination of the 'sources' of the SMB shares, or more appropriately, the resources being shared, as in

'stopping' them on the 'source' machine triggers the hang with UD on the 'object' machine.

This is what I witnessed when I 'manipulated' the 'source' machine in an attempt to get the USB drive back online (mounted).

Stopping the disk array on that machine disconnects or disassociates the resources with the SMB connection on the 'object' machine.

Disconnects certainly.  Disassociates in that once the array is brought back online, it does not re-establish the (SMB) connection on the 'object' machine; nor could it as UD hung at the point of the disconnection.

(Which is why the following message appeared in the log file; the designation was no longer valid)

"Nov 22 00:10:19 Tower kernel: CIFS VFS: BAD_NETWORK_NAME: \\HEADLESS\OCZ-AGILITY3"

Does this make sense as I've presented it?

Where does that leave us?

Right now, I have a machine with UD hung that I can't stop, shutdown, or reboot (without "pulling the plug").

Anything you want me to try before I do so (and face the impact of an unclean shutdown)?

(All of the 'other' operations that were active before, downloads and parity checking, have concluded at this point.)

Cary

 

Please remove the preclear plugin and post diagnostics as requested.  Also change disk with the duplicate uuid.

  • Haha 1
Link to comment

Good Day, missing something and could be a dumb question, but....

 

dlandon created a great script at the beginning of this thread to copy files from unraid to external drive or external drive to unraid. Unfortunately in the portion of the script that uses the $OWNER variable, I don't understand how it works. Its not a command in the linux bash environment and somehow it tests to true when my drive is mounted.

 

I was under the understanding if I was to unmount or mount the drive myself in the unassigned devices GUI the script is not supposed to execute per dlandon's comment
"If you mount and unmount the drive from the Unassigned Devices gui, the drive will mount and unmount but the script will not run because it has detected the 'OWNER' as 'user' and will skip the backup."

 

In the script variable "OWNER" is defined in the script to function as ----->  : "udev" if executed by UDEV, otherwise "user"

 

In the script the line comes up to test if the unassigned GUI mount/unmount button is pressed by the user or system

 

if [ $OWNER = "udev" ]
      then

        logger command here and

        We start the Rsync command here

 

As $OWNER is a variable (cant find anything in bash environment for OWNER), how is it defined to get the information to test? It seems to test true as the script starts the Rsync command ( condition test ----> [ $OWNER = "udev" ] ) must return 0 to be true, so how it works I'm not sure.

 

Also the script does run if I press the mount/unmount in the GUI post script copy completion, which is not supposed to happen, so I must be missing a definition for OWNER variable.

 

My script:

************************************

#!/bin/bash
PATH=/usr/local/sbin:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/bin
## Available variables: 
# AVAIL      : available space
# USED       : used space
# SIZE       : partition size
# SERIAL     : disk serial number
# ACTION     : if mounting, ADD; if unmounting, UNMOUNT; if unmounted, REMOVE; if error, ERROR_MOUNT, ERROR_UNMOUNT
# FSTYPE     : partition filesystem
# LABEL      : partition label
# DEVICE     : partition device, e.g /dev/sda1
# OWNER      : "udev" if executed by UDEV, otherwise "user"
# LOGFILE    : log file for this script

MOUNTPOINT=/mnt/disks/PRORAID-BACKUP/Backup/Array
PROG_NAME="Pro-Raid Backup"

case $ACTION in
  'ADD' )
    #
    # Notify that the device is plugged in.
    #
    echo "External Drive Plugged in: `date`" > $LOGFILE
    /usr/local/emhttp/webGui/scripts/notify -e "Unraid Server Notice" -s "Server Backup" -d "Pro-Raid Backup Mounted" -i "normal"
    sleep 2

    if [ -d $MOUNTPOINT ]
    then
      if [ $OWNER = "udev" ]
      then

        logger -t "$PROG_NAME" Started 
        echo "Pro-Raid Backup Started: `date`" > $LOGFILE

        rsync -av --dry run --stats --delete /mnt/user $MOUNTPOINT/ 2>&1 >> $LOGFILE

        logger -t "$PROG_NAME" Syncing 
        sync -f $MOUNTPOINT

        logger -t "$PROG_NAME" Unmounting
        /usr/local/sbin/rc.unassigned umount $DEVICE

       echo "Pro-Raid Backup Completed: `date`" >> $LOGFILE
        logger -t "$PROG_NAME" Drive Can Be Removed

        /usr/local/emhttp/webGui/scripts/notify -e "Unraid Server Notice" -s "Server Backup" -d "Pro-Raid Backup Completed" -i "normal"
    fi
    else
        logger -t "$PROG_NAME" Not Mounted 
  fi
  ;;

  'REMOVE' )
    #
    # Indicate that the device is unmounted.
    #
    /usr/local/emhttp/webGui/scripts/notify -e "Unraid Server Notice" -s "Server Backup" -d "Pro-Raid Backup Drive Unmounted" -i "normal"
  ;;

  'ERROR_MOUNT' )
    /usr/local/emhttp/webGui/scripts/notify -e "Unraid Server Notice" -s "Server Backup" -d "Could not mount ProRaid Backup" -i "normal"
  ;;

  'ERROR_UNMOUNT' )
    /usr/local/emhttp/webGui/scripts/notify -e "Unraid Server Notice" -s "Server Backup" -d "Could not unmount Pro-Raid Backup" -i "normal"
  ;;
esac

*********************************

 

Thanks.

Link to comment

Ok thx dlandon, so the unassigned devices plugin itself has the “owner” variable defined in its script. I have to get used to the fact Linux (And have learnt this the hard way) is just the base platform and unraid and it’s plugins function on top of that as a separate program calling and interfacing with the overall Linux kernel. If the unassigned devices code is open source, then I would be able to see how it functions. Else it can be challenging to write custom scripts thinking from pure bash Linux interface which it’s not in this case.

Link to comment
9 hours ago, TriBit said:

Ok thx dlandon, so the unassigned devices plugin itself has the “owner” variable defined in its script. I have to get used to the fact Linux (And have learnt this the hard way) is just the base platform and unraid and it’s plugins function on top of that as a separate program calling and interfacing with the overall Linux kernel. If the unassigned devices code is open source, then I would be able to see how it functions. Else it can be challenging to write custom scripts thinking from pure bash Linux interface which it’s not in this case.

I don't understand your concern here.  The $OWNER variable only tells you how the script was initiated.  The UD script is just like any other bash script.  The other variables are for your use in the script as you see fit.

9 hours ago, TriBit said:

If the unassigned devices code is open source, then I would be able to see how it functions.

It is open source, but it's written in php with some html for the web page.  Linux commands are executed to get the device information needed to manage the UD devices.

Link to comment
On 8/24/2019 at 8:36 PM, mustava said:

Hi All,
 

I am encountering an issue where each morning, I log into Unraid to find Unassigned devices unresponsive.
 

Everything in the GUI and array is responsive, except the one disk mounted via unassigned devices and the GUI for unassigned devices. (just the loading animation). The disk is being used by a VM to write to over night as a bit of a scratch disk.

I Also am unable to shutdown or reboot the server in this state, I am required to do a hard power off in order to restart everything.
I am worried doing this is going to cause problems pretty quickly.

 

Has anyone had this issue before?

Capture.PNG

Capture2.PNG

@mustava Did you ever find out what was the issue? I was running 6.5.3 for a long time and every time I tried to upgrade this would happen. I started with a new USB device to see if that was the issue and this started again but I was able to catch some signs that it was UD. I didn't see any replies or solutions to this. I have since uninstalled UD. 

Link to comment
4 hours ago, geonerdist said:

@mustava Did you ever find out what was the issue? I was running 6.5.3 for a long time and every time I tried to upgrade this would happen. I started with a new USB device to see if that was the issue and this started again but I was able to catch some signs that it was UD. I didn't see any replies or solutions to this. I have since uninstalled UD. 

Possibly your problems aren't exactly the same. Why didn't you ask for help in this thread yourself?

Link to comment
5 hours ago, geonerdist said:

@mustava Did you ever find out what was the issue? I was running 6.5.3 for a long time and every time I tried to upgrade this would happen. I started with a new USB device to see if that was the issue and this started again but I was able to catch some signs that it was UD. I didn't see any replies or solutions to this. I have since uninstalled UD. 

I'm still waiting for someone to supply some diagnostics so I can help troubleshoot.  Can't offer any solutions until I can determine the problem.

Link to comment
On 11/26/2019 at 4:52 AM, dlandon said:

I don't understand your concern here.  The $OWNER variable only tells you how the script was initiated.  The UD script is just like any other bash script.  The other variables are for your use in the script as you see fit.

It is open source, but it's written in php with some html for the web page.  Linux commands are executed to get the device information needed to manage the UD devices.

 

Although may not be considered a concern, the unassigned devices plugin provides the ability to add a custom script using Linux bash command. The code you provided was not clear how it functioned or how to use those variables as it's defined within your plugin code. So beyond that, no big deal, I started to to test some scripts myself. I came across some odd behavior. For example the following code should mount and un-mount a drive in linux using UUID.

 

In linux command line:

 

mount UUID= "$UID" "$MPOINT"  ---where UID is the UID of your target device (as shown with blkid) and MPOINT is the path you want to mount.

 

to un-mount just:

 

umount $MOUNTPOINT

 

These 2 functions return an error when the external device was plugged in (Note: without auto mount enabled or a script provided in unassigned devices). Techincally I'm aware I don't have to use mount command with the Auto mount feature and likely not the UUID as the script is unique to the device. 

 

The only way to get these 2 functions to work correctly is to mount and un-mount the device within your unassigned devices plugin GUI button. After that they work fine and you can even see the mount/umount icon change within the plugin. Its almost like when the external device is plugged in, the unassigned devices plugin did not interface/communicate with linux kernal properly at first. This left me troubleshooting code that should work.

 

The code line "/usr/local/sbin/rc.unassigned umount $DEVICE" if you had not provided this great script I would have never known this. My code would have been just umount $MOUNTPOINT. I haven't tested this as a replacement, but I expect it would fail to un-mount the drive.

 

So I guess what is the issue with the failed commands?

 

I assume the unassigned devices script will execute when the plugin sees a drive attached regardless if its set to auto mount?

 

I've been using the Pro product since 2008 (Very Unique). Leaps and bounds amazing as of today. I thank all the community developers and Limetech for developing such an amazing platform. Thanks for all your hard work!

 

 

 

 

Link to comment
3 hours ago, TriBit said:

 

Although may not be considered a concern, the unassigned devices plugin provides the ability to add a custom script using Linux bash command. The code you provided was not clear how it functioned or how to use those variables as it's defined within your plugin code. So beyond that, no big deal, I started to to test some scripts myself. I came across some odd behavior. For example the following code should mount and un-mount a drive in linux using UUID.

 

In linux command line:

 

mount UUID= "$UID" "$MPOINT"  ---where UID is the UID of your target device (as shown with blkid) and MPOINT is the path you want to mount.

 

to un-mount just:

 

umount $MOUNTPOINT

 

These 2 functions return an error when the external device was plugged in (Note: without auto mount enabled or a script provided in unassigned devices). Techincally I'm aware I don't have to use mount command with the Auto mount feature and likely not the UUID as the script is unique to the device. 

 

The only way to get these 2 functions to work correctly is to mount and un-mount the device within your unassigned devices plugin GUI button. After that they work fine and you can even see the mount/umount icon change within the plugin. Its almost like when the external device is plugged in, the unassigned devices plugin did not interface/communicate with linux kernal properly at first. This left me troubleshooting code that should work.

 

The code line "/usr/local/sbin/rc.unassigned umount $DEVICE" if you had not provided this great script I would have never known this. My code would have been just umount $MOUNTPOINT. I haven't tested this as a replacement, but I expect it would fail to un-mount the drive.

 

So I guess what is the issue with the failed commands?

 

I assume the unassigned devices script will execute when the plugin sees a drive attached regardless if its set to auto mount?

 

I've been using the Pro product since 2008 (Very Unique). Leaps and bounds amazing as of today. I thank all the community developers and Limetech for developing such an amazing platform. Thanks for all your hard work!

Don't mount or unmount manually.  Use the rc.unassigned script.  It will manage things properly.

3 hours ago, TriBit said:

 

I assume the unassigned devices script will execute when the plugin sees a drive attached regardless if its set to auto mount?

The script runs when the drive is mounted, unmounted, or there are errors.  The auto mount has nothing to do with the script execution.

Link to comment
48 minutes ago, geonerdist said:

Thought I attached it to my original response. 

tower-diagnostics-20191127-2342.zip 82.35 kB · 1 download

You mounted the seagate disk.  I don't see anything in the log,  but I see issues in the smart report:

SATA Version is:  SATA 3.1, 6.0 Gb/s (current: 3.0 Gb/s)

7 Seek_Error_Rate         POSR--   084   060   045    -    256581222

195 Hardware_ECC_Recovered  -O-RC-   079   064   000    -    87027788

I am not an expert on disk drives, but this looks like a controller or cable issue.  Disk problems can cause UD to hang if the Linux commands used to check the disk hang.

Link to comment

For anyone having issues with UD appearing to hang, please extract and copy the attached lib.php file.

cp lib.php /usr/local/emhttp/plugins/unassigned.devices/include/

I've added timeouts to all shell_exec commands to terminate any hanging commands with logging if it takes too long.  You'll see a warning in the log.  Hopefully UD won't hang any more.

 

lib.zip

  • Thanks 1
Link to comment
19 hours ago, dlandon said:

You mounted the seagate disk.  I don't see anything in the log,  but I see issues in the smart report:


SATA Version is:  SATA 3.1, 6.0 Gb/s (current: 3.0 Gb/s)

7 Seek_Error_Rate         POSR--   084   060   045    -    256581222

195 Hardware_ECC_Recovered  -O-RC-   079   064   000    -    87027788

I am not an expert on disk drives, but this looks like a controller or cable issue.  Disk problems can cause UD to hang if the Linux commands used to check the disk hang.

Good catch, thanks....better brush up on my smart report skills. Would it matter if I pulled the diagnostics after I had rebooted and uninstalled -UD? I'm going to see if it'll hang again and get diagnostics downloaded before it becomes completely unresponsive. Thanks again!

Link to comment
  • trurl pinned this topic

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.