I'm new to UNRAID and I build a new system which consists of 6 1.5TB HD.  When I stop the array I get a "waiting..." message on the bottom and it appears to never stop.  I have already format each of the 1.5TB HD and ran the parity sync and when I stop the array it just keep "waiting..." forever it seams.  Is this something that should happen quickly or does it take a very long time?  When I ran the parity sync I was getting around 23,000K/sec. 

 

Is there someplace I can look to see the progress of the array stopping?  Telnet into the box or something?  The web browser just hangs and you can't do anything else.  I get the impression that there is something wrong here.

Did you refresh the browser?

 

Did you refresh the browser?

 

 

Yes, I did and it still keep saying "Waiting..." at the bottom the web page.  I'm assuming that stop the array should happen in seconds not minutes or hours, is this correct?  Considering this is a new system and no data on any of the disks yet.

In order to shut down unRAID must first shut down SAMBA, then un-mount the data drives, then stop the array.  To un-mount a disk, it must spin it up, as it writes the mount status to the file-system on the disk.  There will be a delay if all your disks are spun down, as each is spun up in turn as it is un-mounted.  This could take 30 seconds or more if you have a lot of disks.

 

Are you running any scripts or processes that were not supplied in the base distribution?  Or, have you logged in via telnet and "CD'd" to a folder on one of your disks?

 

The reason I ask is that if a disk is "busy" it cannot be un-mounted.  (Busy = a file on it is open, or, it is the "current directory" for a process.)

 

If a disk cannot be un-mounted, it will cause the unRAID "emhttp" process to become very confused as it attempts to display the disks.  I've not seen it hang the browser, but the only way to know for sure what is happening is to log in via telnet and type:

tail -50 /var/log/syslog

 

You will see the last 50 lines of the system log.  Any errors would be posted there.

 

If not sure how to interpret the syslog, post a copy in this thread.  Instructions are in the wiki here, at this link

 

Joe L.

Telnet in and run this command to see if any processes are running with athave files open on the array:

 

fuser -m /dev/md*

In order to shut down unRAID must first shut down SAMBA, then un-mount the data drives, then stop the array.  To un-mount a disk, it must spin it up, as it writes the mount status to the file-system on the disk.  There will be a delay if all your disks are spun down, as each is spun up in turn as it is un-mounted.  This could take 30 seconds or more if you have a lot of disks.

 

Are you running any scripts or processes that were not supplied in the base distribution?  Or, have you logged in via telnet and "CD'd" to a folder on one of your disks?

 

The reason I ask is that if a disk is "busy" it cannot be un-mounted.  (Busy = a file on it is open, or, it is the "current directory" for a process.)

 

If a disk cannot be un-mounted, it will cause the unRAID "emhttp" process to become very confused as it attempts to display the disks.   I've not seen it hang the browser, but the only way to know for sure what is happening is to log in via telnet and type:

tail -50 /var/log/syslog

 

You will see the last 50 lines of the system log.  Any errors would be posted there.

 

If not sure how to interpret the syslog, post a copy in this thread.  Instructions are in the wiki here, at this link

 

Joe L.

 

I am not running scripts or processes that were not supplied in the base distribution.  I'm running unRAID Server Plus v4.4-beta2 on a SanDisk Micro Cruzer 4GB. 

 

I've attached a screenshot of what the GUI looks like after I click the "Stop" button and I included my syslog as well.  I let it run for over 30 minutes and the GUI never respond back after I hit the "Stop", it just keep saying "Wait..." on the bottom of the screen.  Looking at the syslog it appears to hang on the "sync" command.  I also made sure I'm not on any of the shares nor within any of the directories on the filesystem when I click the "stop" button. 

 

I then telnet into the box and issue a "sync" command which hung for over 10-15 minutes I couldn't get back to prompt with a ctrl-c.  So I opened another telnet window and issue a "shutdown -h now" to attempt to shutdown the system this didn't work either.  The only way I could get the system to shutdown was to hit the power button.  This has happen to me each of the three times I've tried to stop my array.  Each time I restart the system afterword it runs the parity sync all over again. 

 

My rig consists of the following:

 

ASUS P4P800 Deluxe Motherboard

Prescott 3.4Ghz P4 (Hyper-thread) Processor

Corsair CMX512-3200C2PRO (400Mhz) 2GB of RAM

NORCO RPC-4020 Hot-swappable Case

Toughpower 750W PSU

Promise SATA300 TX4 (Standard PCI slot)

Six Seagate ST31500341AS 1.5TB SATA300 HD (Upgraded to firmware CC1H)

ATI Rage 8MB PCI Video Card

Sandisk Micro Cruizer 4GB

 

BTW, I'm running two of the hard drives on the onboard SATA controller and the other four on the Promise SATA TX4 card.  And I ran the memtest for 24 hours with no errors.

 

At this point I'm stumped as to why it hangs the system when I try to stop the array.  Its quite possible I am doing something wrong because I'm not too familar with unRAID.  Any help you can provide is greatly appreciated. 

 

I tried to stop the array again and its still appears to be hanging on the sync command:

 

Dec 12 15:52:08 sumner-nas emhttp: shcmd (9): killall -HUP smbd

Dec 12 15:52:08 sumner-nas ifplugd(eth0)[1496]: Program executed successfully.

Dec 12 15:52:31 sumner-nas in.telnetd[1705]: connect from 192.168.1.169 (192.168.1.169)

Dec 12 15:52:47 sumner-nas login[1706]: invalid password for `UNKNOWN'  on `pts/0' from `192.168.1.169'

Dec 12 15:52:48 sumner-nas login[1706]: ROOT LOGIN  on `pts/0' from `192.168.1.169'

Dec 12 15:53:06 sumner-nas ntpd[1524]: Cannot find existing interface for address 208.75.88.4

Dec 12 15:53:06 sumner-nas ntpd_initres[1526]: ntpd indicates no data available!

Dec 12 15:54:06 sumner-nas ntpd[1524]: Cannot find existing interface for address 208.75.88.4

Dec 12 15:54:06 sumner-nas ntpd_initres[1526]: ntpd indicates no data available!

Dec 12 15:54:20 sumner-nas login[1552]: ROOT LOGIN  on `tty1'

Dec 12 15:55:06 sumner-nas ntpd[1524]: Cannot find existing interface for address 208.75.88.4

Dec 12 15:55:06 sumner-nas ntpd_initres[1526]: ntpd indicates no data available!

Dec 12 15:56:06 sumner-nas ntpd[1524]: Cannot find existing interface for address 208.75.88.4

Dec 12 15:56:06 sumner-nas ntpd_initres[1526]: ntpd indicates no data available!

Dec 12 15:57:05 sumner-nas ntpd[1524]: Listening on interface #2 eth0, 192.168.1.3#123 Enabled

Dec 12 15:57:54 sumner-nas ntpd[1524]: synchronized to 208.75.88.4, stratum 2

Dec 12 15:57:54 sumner-nas ntpd[1524]: kernel time sync status change 0001

Dec 12 16:12:51 sumner-nas kernel: mdcmd (64): nocheck

Dec 12 16:12:51 sumner-nas kernel: md: md_do_sync: got signal, exit...

Dec 12 16:12:51 sumner-nas kernel: md: recovery thread sync completion status: -4

Dec 12 16:13:10 sumner-nas kernel: mdcmd (66): clear

Dec 12 16:13:14 sumner-nas emhttp: shcmd (10): killall -w smbd nmbd

Dec 12 16:13:16 sumner-nas emhttp: Spinning up all drives...

Dec 12 16:13:16 sumner-nas emhttp: shcmd (11): sync

 

Just for kicks and giggles I tried to create a new share and the damn GUI hangs too.  It appears to be hanging on the following command:

 

shcmd (10): mkdir -m 700 '/mnt/user/movies'

 

I let it run for 15 minutes and it never created the share and the GUI is hung with the "waiting.." message.

 

I tried going to the /mnt/user/movies directory on the system and it hung when I cd into /mnt/user and I couldn't even hit ctrl-c to get out of it.

 

There must be something seriously wrong with my setup because I can't stop my array nor create a share.  I have a few theories as to where the problem might exist:

 

1. I'm using the new Seagate 1.5TB SATA HD, maybe I'm hitting the known freezing issue?  I did however, contact Seagate and upgrade the firmware on all my drives and it made no difference.

2. I'm using an old motherboard P4P800-E Deluxe (w/ latest BIOS update) which is listed in the Hardware Compatibility list, but maybe it just can't handle this type of configuration?

3. I'm using the beta version of unRAID 4.4-beta2, maybe I should downgrade?

4. Maybe I should start smaller and try just three of my 1.5TB HD and see if the behavior is different?

 

I'm really stuck and need help from you experts out there because right now I have a very expensive boat anchor. ;-(

 

I've anyone has any suggestions for me to try please let me know.  I'm deperate at this point.

This series of error messages in your syslog usually indicates you need to run the reiserfsck file-system-repair tool on your file-system.

 

Dec 11 20:44:05 sumner-nas kernel: kernel BUG at fs/reiserfs/bitmap.c:1222!
Dec 11 20:44:05 sumner-nas kernel: invalid opcode: 0000 [#1] SMP 
Dec 11 20:44:05 sumner-nas kernel: Modules linked in: md_mod ata_piix sata_promise piix ide_core skge libata [last unloaded: md_mod]
Dec 11 20:44:05 sumner-nas kernel: 
Dec 11 20:44:05 sumner-nas kernel: Pid: 1793, comm: emhttp Not tainted (2.6.26.5-unRAID #9)
Dec 11 20:44:05 sumner-nas kernel: EIP: 0060:[<c01878f1>] EFLAGS: 00210246 CPU: 1
Dec 11 20:44:05 sumner-nas kernel: EIP is at reiserfs_cache_bitmap_metadata+0x11/0x4f
Dec 11 20:44:05 sumner-nas kernel: EAX: c214c000 EBX: f8865ea8 ECX: f8865ea8 EDX: 00001000
Dec 11 20:44:05 sumner-nas kernel: ESI: f5dd2480 EDI: f6c5ee00 EBP: 00002baa ESP: f6c5bde8
Dec 11 20:44:05 sumner-nas kernel:  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
Dec 11 20:44:05 sumner-nas kernel: Process emhttp (pid: 1793, ti=f6c5a000 task=f7b02470 task.ti=f6c5a000)
Dec 11 20:44:05 sumner-nas kernel: Stack: f5dd2480 15d50000 c0187a98 f885b000 f6c5ee00 f6c5be6c f885b000 c2124000 
Dec 11 20:44:05 sumner-nas kernel:        c01a41f9 00000000 00002baa 15d50f5e f6c5ee00 15d50f50 00001000 c2124000 
Dec 11 20:44:05 sumner-nas kernel:        f885b000 00002bab 00002bab 00000f5e 15d50f50 00000000 00000000 c0376130 
Dec 11 20:44:05 sumner-nas kernel: Call Trace:
Dec 11 20:44:05 sumner-nas kernel:  [<c0187a98>] reiserfs_read_bitmap_block+0xaa/0xb2
Dec 11 20:44:05 sumner-nas kernel:  [<c01a41f9>] reiserfs_resize+0x331/0x518
Dec 11 20:44:05 sumner-nas kernel:  [<c01965c5>] reiserfs_remount+0xd3/0x33e
Dec 11 20:44:05 sumner-nas kernel:  [<c015702b>] do_remount_sb+0x107/0x12e
Dec 11 20:44:05 sumner-nas kernel:  [<c016837d>] do_remount+0xd6/0x106
Dec 11 20:44:05 sumner-nas kernel:  [<c0168d46>] do_mount+0x11c/0x19b
Dec 11 20:44:05 sumner-nas kernel:  [<c030c8f2>] error_code+0x72/0x78
Dec 11 20:44:05 sumner-nas kernel:  [<c030d16e>] iret_exc+0x3be/0x83b
Dec 11 20:44:05 sumner-nas kernel:  [<c0168e32>] sys_mount+0x6d/0xab
Dec 11 20:44:05 sumner-nas kernel:  [<c0102b16>] syscall_call+0x7/0xb
Dec 11 20:44:05 sumner-nas kernel:  [<c0300000>] acpi_processor_hotplug_notify+0x2/0x1f3

 

Instructions for how to run reiserfsck on disks is here in the wiki: http://lime-technology.com/wiki/index.php?title=Check_Disk_Filesystems

I found this post within Newegg regarding the Promise SATA300 TX4 used with the ASUS P4P800 motherboard:

 

Pros: Cheap price for a 4 port sata conroller.

Cons: Doesn't work with my Asus P4P800 Deluxe motherboard.

Causes system to hang before I can even boot into Windows.

Other Thoughts: Don't buy if you have a P4P800 Deluxe.

 

http://www.newegg.com/Product/ProductReview.aspx?Item=16-102-062&SortField=3&SummaryType=0&Pagesize=25&SelectedRating=-1&PurchaseMark=&VideoOnlyMark=False

 

I open a web support ticket with Promise to confirm whether this card is compatible with my motherboard.  My motherboard isn't listed within the supported motherboard listed provided by Promise here:

 

http://www.promise.com/support/download/download2_eng.asp?productID=139&category=compatibility&os=100

 

So it looks like I'm screwed but I'll do more research before making that conclusion.  So its looking like I will need to replace my motherboard which really sucks because I was hoping to reuse the hardware I had laying around the house to minimize cost.  I'll do more testing anyone using P4P800 with these Promise cards?

 

This series of error messages in your syslog usually indicates you need to run the reiserfsck file-system-repair tool on your file-system.

 

Instructions for how to run reiserfsck on disks is here in the wiki: http://lime-technology.com/wiki/index.php?title=Check_Disk_Filesystems

 

When I issue the umount /dev/md1 command I get "device is busy".  How do I work around this?  I stop the parity check but it still won't let me do it.

 

I tried doing a fuser -u /dev/md1 and then another umount /dev/md1 but I still get device is busy.

Since /dev/md1 is /mnt/disk1, try typing

 

fuser -cuv /dev/md1

 

That will show you the processes that have the file system open. 

 

Then kill each of them with

kill -TERM PID

where PID = process ID reported by fuser.

I tried doing a fuser -u /dev/md1 and then another umount /dev/md1 but I still get device is busy.

The "fuser" command does not terminate the processes, it only reports them to you.  If you did not kill them, they are still there, and the device will still be busy.

 

 

Since /dev/md1 is /mnt/disk1, try typing

 

fuser -cuv /dev/md1

 

That will show you the processes that have the file system open.   

 

Then kill each of them with

kill -TERM PID

where PID = process ID reported by fuser.

 

I ran fuser -cuv /dev/md1 and it comes back with no results.  And the device is still busy.  And I tried the killall command also.  Something is really wrong here. 

I've also notice the kernel is giving an error

 

Dec 12 20:23:09 sumner-nas kernel: ------------[ cut here ]------------
Dec 12 20:23:09 sumner-nas kernel: WARNING: at kernel/exit.c:965 do_exit+0x28/0x52c()
Dec 12 20:23:09 sumner-nas kernel: Modules linked in: md_mod ata_piix sata_promise libata skge piix ide_core [last unloaded: md_mod]
Dec 12 20:23:09 sumner-nas kernel: Pid: 1643, comm: emhttp Tainted: G      D   2.6.26.5-unRAID #9
Dec 12 20:23:09 sumner-nas kernel:  [<c011b234>] warn_on_slowpath+0x40/0x65
Dec 12 20:23:09 sumner-nas kernel:  [<c012c4dc>] atomic_notifier_call_chain+0x9/0xc
Dec 12 20:23:09 sumner-nas kernel:  [<c02475dc>] notify_update+0x1f/0x22
Dec 12 20:23:09 sumner-nas kernel:  [<c024b073>] vt_console_print+0x239/0x247
Dec 12 20:23:09 sumner-nas kernel:  [<c024ae3a>] vt_console_print+0x0/0x247
Dec 12 20:23:09 sumner-nas kernel:  [<c011b2ae>] __call_console_drivers+0x4f/0x5b
Dec 12 20:23:09 sumner-nas kernel:  [<c012c354>] up+0x9/0x2a
Dec 12 20:23:09 sumner-nas kernel:  [<c011b6cb>] release_console_sem+0x16d/0x186
Dec 12 20:23:09 sumner-nas kernel:  [<c0121b79>] run_timer_softirq+0x2f/0x13f
Dec 12 20:23:09 sumner-nas kernel:  [<c011edea>] __do_softirq+0x5d/0xc1
Dec 12 20:23:09 sumner-nas kernel:  [<c010e5a4>] smp_apic_timer_interrupt+0x6e/0x7a
Dec 12 20:23:09 sumner-nas kernel:  [<c010355c>] apic_timer_interrupt+0x28/0x30
Dec 12 20:23:09 sumner-nas kernel:  [<c011d8a5>] do_exit+0x28/0x52c
Dec 12 20:23:09 sumner-nas kernel:  [<c011bb4d>] printk+0x14/0x18
Dec 12 20:23:09 sumner-nas kernel:  [<c0103dc6>] die+0x10f/0x114
Dec 12 20:23:09 sumner-nas kernel:  [<c0103ef4>] do_invalid_op+0x0/0x6b
Dec 12 20:23:09 sumner-nas kernel:  [<c0103f56>] do_invalid_op+0x62/0x6b
Dec 12 20:23:09 sumner-nas kernel:  [<c01878f1>] reiserfs_cache_bitmap_metadata+0x11/0x4f
Dec 12 20:23:09 sumner-nas kernel:  [<c030b5c4>] schedule+0x5b7/0x5d8
Dec 12 20:23:09 sumner-nas kernel:  [<c01f3bf5>] generic_make_request+0x1e5/0x213
Dec 12 20:23:09 sumner-nas kernel:  [<c030b875>] __wait_on_bit+0x50/0x58
Dec 12 20:23:09 sumner-nas kernel:  [<c0170d14>] sync_buffer+0x0/0x33
Dec 12 20:23:09 sumner-nas kernel:  [<c0170d14>] sync_buffer+0x0/0x33
Dec 12 20:23:09 sumner-nas kernel:  [<c030c8f2>] error_code+0x72/0x78
Dec 12 20:23:09 sumner-nas kernel:  [<c01878f1>] reiserfs_cache_bitmap_metadata+0x11/0x4f
Dec 12 20:23:09 sumner-nas kernel:  [<c0187a98>] reiserfs_read_bitmap_block+0xaa/0xb2
Dec 12 20:23:09 sumner-nas kernel:  [<c01a41f9>] reiserfs_resize+0x331/0x518
Dec 12 20:23:09 sumner-nas kernel:  [<c01965c5>] reiserfs_remount+0xd3/0x33e
Dec 12 20:23:09 sumner-nas kernel:  [<c015702b>] do_remount_sb+0x107/0x12e
Dec 12 20:23:09 sumner-nas kernel:  [<c016837d>] do_remount+0xd6/0x106
Dec 12 20:23:09 sumner-nas kernel:  [<c0168d46>] do_mount+0x11c/0x19b
Dec 12 20:23:09 sumner-nas kernel:  [<c0166ea2>] copy_mount_options+0x26/0x109
Dec 12 20:23:09 sumner-nas kernel:  [<c0168e32>] sys_mount+0x6d/0xab
Dec 12 20:23:09 sumner-nas kernel:  [<c0102b16>] syscall_call+0x7/0xb
Dec 12 20:23:09 sumner-nas kernel:  [<c0300000>] acpi_processor_hotplug_notify+0x2/0x1f3
Dec 12 20:23:09 sumner-nas kernel:  =======================
Dec 12 20:23:09 sumner-nas kernel: ---[ end trace a15f40c196406a28 ]---

I might have fixed my issue but I won't know for sure until midday tomorrow when the parity check completes.  Here are the steps I followed:

 

1. Verified that all six disks work good by running tests using Seatools

2. Formatted all six disks and removed partitions and MBR

3. Upgraded to unRAID 4.5-Beta1

4. Deleted my super.dat file

5. Comment out parity and disk lines in disk.cfg

6. Attached disk1 to array

7. Format disk1

8. Initalize Array

9. Copied file to disk1

10. Stop Array

11. Started Array

12. Add disk2

13. Repeat steps 7-10

14. Add all six disks

15. Ran parity sync

 

With just a few disks I was able to stop and start the array with no problems.  I was able to copy files over to RAID without any problems.  The real test will be to see if I can stop the array and after parity sync is finished.

I can now stop and start the array with all six drive with no problems.  I suspect I had a corrupt disk that got resolved when I reformatted everything and started from scratch.