Joe L.

The unRAID web interface does not refresh itself. If you can access the data, the disks are mounted.

Are you cleanly stopping the array before shutting the server down? I can see it taking a long time replaying the file-system-journals if you do not shut down cleanly. (as long as 30 minutes or more) This would be noted in the system log though. As far as disk accesses, it sounds like something is using your disks. Install the inotifywatch package to learn what is using them. Joe L.

And you will for most small and medium sized files, since you are writing to the disk buffer cache (until it fills) With 4GB of RAM, most files fit entirely in RAM and the writing is limited mostly by network I/O. When reading, you are limited by the disk I/O speed (unless the file is still in the disk buffer cache) Add lines to the end of your config/go file. You are welcome.

As moderator I removed your syslog. Your email/password were in it. (I was the only downloader, so you are probably safe, but you should change your email password regardless) You really need to turn OFF the debugging mode you currently have enabled as it puts your email/password in the syslog. (probably part of the e-mail setup/config screen) disk1 seems to have lots of "media errors" (un-readable sectors) Does it respond and provide output to hdparm -i /dev/sde ( I think it is /dev/sde ) or, if on a different controller than the rest of your disks you might try smartctl -a /dev/sde post its SMART report. Another disk, /dev/hdb seems to also have errors. Is this an IDE drive? (not an SATA drive?) Is this the one not responding t the SMART report request? Jun 10 17:47:02 Tower kernel: hdb: task_pio_intr: status=0x51 { DriveReady SeekComplete Error } Jun 10 17:47:02 Tower kernel: hdb: task_pio_intr: error=0x04 { DriveStatusError } Jun 10 17:47:02 Tower kernel: hdb: possibly failed opcode: 0xa1 Edit: It seems to be a WD-EADS drive according to your screen shot earlier. If so, it is an SATA drive and you have the disk controller set in IDE emulation mode. You need to set it in your BIOS to ACHI mode. (Take it out of legacy mode, or whatever they cal it in your BIOS) Right now it is running in a much slower mode designed to emulate IDE disks so it can boot Win-XP or prior.

I really can't answer that question, since if something overwrote the superblock AND parity was updated with it, then both will have the same contents. You can;t easily tell without un-assigning, or disconnecting disk3 so parity is used to re-construct the disk whose superblock contents apparently have been mangled. If you decide to try, do it this way so you can easily get back to the same status as now. Stop the array Copy the config/super.dat file to config/super.orig cp /boot/config/super.dat /boot/config/super.orig With the array stopped, un-plug disk3. (or un-assign it) Start the array If the disk mounts and the data on it is accessible, then parity is able to reconstruct it. You are in luck. If not, try the same "dd" commands, but this time on /dev/md3 The "Reiserfs" string should appear pretty close to the beginning of output. Odds are it will not if the disk could not be mounted. Now, you can stop the array once more and then re-connect the drive (r-reassign it) Before you re-start the array, copy the super.orig file back to super.dat cp /boot/config/super.orig /boot/config/super.dat DO NOT RE-START THE ARRAY, BUT INSTEAD type reboot The reboot is to let emhttp see the original super.dat file once more and be un-aware of your experiment in disconnecting/unassigning it. Since the snapshot copy was taken with the array cleanly stopped, it should have no issues when you reboot. (the disk will probably still not mount, but that is a different issue because of the corrupted superblock)

You can have thousands of "read" errors, and a drive will not be taken out of service. This is expected. The drive WILL be taken out of service on a single "write" failure. The linux kernel will often re-set the disk controller and retry and not even report the error upward to the calling process. If all the indicators are green, then the disk is still being accessed. What do you get when you attempt to get a smart report? How are you attempting to get it? Joe L.

Can you show a screen-shot of the unRAID main page showing the errors? Also, please attach a syslog to your next post. (you can download it easily from the syslog page in unMENU)

The problem is when a process is keeping a disk busy and emhttp will wait forever to be able to un-mount a disk. Therefore, handing complete control to emhttp is not the best solution. I think we need to create a new clean-powerdown plugin. (as an alternative to the current package) add a "event" script in the new plugin to set an array status file to the current status in /var/tmp This file will let us know if emhttp is processing the events as expected. By using the file contents, we do not have to query /proc/mdcmd. when the new "clean powerdown" is invoked: if emhttp is running and responding invoke the power down "button" URL using wget x=60 while x > 0 do sleep 1 x = x - 1 if array status (in the above file) is stopped, exit loop done At this point, we've given emhttp 60 seconds time to stop the add-ons and un-mount the drives, etc.If it completed the task in less time, we are here and the status file should show the array is stopped/powering down the array. we probably don't need to do anything more. If still trying to un-mount the disks, then we can selectively kill processes holding them busy, and enter another while loop waiting for additional time for unRAID to un-mount the disks. If the timers expire, and the disks are still not un-mounted, then we can proceed without emhttp figuring it is no longer doing all that is needed. We can change the powerdown package. If emhttp is running, it can communicate with emhttp and send the appropriate button presses then wait for emhttp to unmount the filesystems. The real reason it was created was to kill of any processes that had the disks mounted and unmount them as a last ditch effort.

Sorry /root/powerdown, not /boot/powerdown.... :-) Oh and by the way, running the offending script without the rsync component now fails with a "Kernel panic" Before killing the powerdown command this worked fine. Things are getting worse not better.... :-) ls -l /root/powerdown gives: lrwxrwxrwx 1 root root 25 2013-06-03 19:43 /root/powerdown -> /usr/local/sbin/powerdown* you are indeed linked to the stock unRAID powerdown.

Sorry /root/powerdown, not /boot/powerdown.... :-) And what do you see when you type: ls -l /root/powerdown

Now which powerdown points to /boot/powerdown dated Jun 3 2013 and it looks like: powerdown 393/393 100% #!/bin/bash # # Helper script to gracefully power-down unRAID server. # Works only if webGui is running and listening on port 80. # Access a blank page in case this is first request since startup. /usr/bin/wget -q -O - localhost/update.htm >/dev/null # Have emhttp do all the work as if user clicked 'shutdown' in webGui. /usr/bin/wget -q -O - localhost/update.htm?shutdown=apply >/dev/null Rebooting and retesting failing script to see what happens now.... sorry, but the default unRAID distribution does not include a /boot/powerdown command. It must be something you've put there.

It appears as if disk 3 is: Jun 9 19:37:22 Tower kernel: md: import disk3: [8,112] (sdh) WDC_WD20EARX-00PASB0_WD-WCAZAK100188 size: 1953514552 You said the disk setting shows mbr-unalligned... Let's see what is actually there on the disk by typing the following: dd if=/dev/sdh count=195 | od -c -A d | sed 30q The output should look a lot like this... Note where the string "R e I s E r 2 F s" appears.... Let's see if yours is at the same address, or one sector further. Output on one of my drives looks like this (it has a file-system starting on sector 63): 195+0 records in 195+0 records out 99840 bytes (100 kB) copied, 0.00169403 s, 58.9 MB/s 0000000 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 * 0000448 \0 \0 203 \0 \0 \0 ? \0 \0 \0 361 _ 8 : \0 \0 0000464 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 * 0000496 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 U 252 0000512 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 * 0097792 376 \v G \a e \a - \0 \a 212 267 001 022 \0 \0 \0 0097808 \0 \0 \0 \0 \0 \0 \0 \0 004 \0 \0 % 254 227 \ 0097824 204 003 \0 \0 036 \0 \0 \0 \0 \0 \0 \0 \0 020 314 003 0097840 220 \0 002 \0 R e I s E r 2 F s \0 \0 \0 0097856 003 \0 \0 \0 005 \0 217 016 002 \0 \0 \0 204 ] \0 \0 0097872 001 \0 \0 \0 353 300 256 263 242 347 N 347 264 362 315 364 0097888 345 V 253 366 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 0097904 \0 \0 \0 \0 \a \0 036 \0 255 262 303 M \0 N 355 \0 0097920 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 We are expecting the line with R e I s E r 2 F s to appear at address 0097840 (if MBR-un-alligned) or 512 bytes further (if MBR-4k-alligned) To assist in the analysis, also post the output of fdisk -lu /dev/sdh Joe L.

Joe ... My understanding is that the script installed via UnMenu (the "Clean PowerDown" script) does not have this restriction -- right? Correct, the package installed via unMENU does not use the powerdown "button" built into unRAID's emhttp. That is my understanding... No "script" named "powerdown" is run when the "Power Down" button on emhttp's interface is run. Eventually, after stopping the array, the script in /etc/rc.d/rc.0 is invoked. It will invoke /etc/rc.d/rc.local_shutdown if it exists as well as stop other services via their own rc.XXXXXXXXX (service name) script. In rc.local_shutdown I have a line added by the clean-powerdown install script that invokes "rc.unRAID stop" rc.unRAID is where the bulk of the "clean-powerdown" script exists. Then, it performs several "sync" commands, turns off swap, un-mounts any remaining mounted file-systems, The last thing it does is invoke /sbin/poweroff That is what we are trying to determine.

Oh, it's nothing special really. It's mostly the stock powerdown, just slightly modified to make it a little more general. It doesn't (yet) have functionality like that old plugin that you're using. And no special installation is needed, you can simply copy it over the stock powerdown from the go script. It is slightly more complicated than at first glance. Lime-technology distributes a "powerdown" command in /usr/local/sbin/powerdown. It is a shell script that looks like this: #!/bin/bash # # Helper script to gracefully power-down unRAID server. # Works only if webGui is running and listening on port 80. # Access a blank page in case this is first request since startup. /usr/bin/wget -q -O - localhost/update.htm >/dev/null # Have emhttp do all the work as if user clicked 'shutdown' in webGui. /usr/bin/wget -q -O - localhost/update.htm?shutdown=apply >/dev/null The stock script depends on emhttp responding. The clean powerdown command package is installed at /sbin/powerdown Unfortunately, the PATH for unRAID has /usr/local/sbin before /sbin so just invoking "powerdown" will get the lime-tech supplied command. To eliminate any confusion, the unMENU clean-powerdown package re-names the lime-tech supplied command to "/usr/local/sbin/unraid_powerdown" after installing itself as /sbin/powerdown. If unRAID was explicitly calling /usr/local/sbin/powerdown, using a full path, it would not be found. (To my knowledge, it is called with a relative path, so it is found) Joe L.

I was not the author. I don't think it has ever been updated. I do know some download it directly. Do you know of an updated version? Or an alternative? You might be correct in that it does not hook into the current unRAID's event system. A lot may have to do with HOW the shutdown is being initiated. Questions that might give more clues are: Do you have SimpleFeatures web-interface installed? Do you have the "clean-powerdown" package installed? What is the output when you type: 'which powerdown' Do you have the apcupsd UPS package installed (through unMENU, or directly downloaded)? Do you have the apcupsd UPS plugin installed (through SimpleFeatues)? Are you stopping the array first using the web-interface? Are you using the web-interface to power down the array? Are you using the server chassis "power button" (short press) to initiate a power down? Are you using "control-Alt-delete" to initiate a power down? Joe L.

Attach a syslog to your next post. DO NOT format the disk. To unRAID, any disk it cannot mount is unformatted. You'll probably need t check the file-system on the disk that will not mount. something like this (pretending the disk is disk5 for this example) reiserfsck --check /dev/md5 use /dev/md1 if disk1, /dev/md9 if disk9, /dev/md20 if disk20, etc

This topic has been moved to User Customizations. [iurl]http://lime-technology.com/forum/index.php?topic=27843.0[/iurl]

Well, cant you just pull out SF and reboot? after that it should just give you the stock gui. To do it without rebooting would be more of a pain, you would have to go back and replace all the gui files in active memory with the originals... i think the point is that when the emhttp goes unresponsive, it becomes increasingly difficult to *safely* shutdown the array. exactly. This happened again yesterday, SF died again, and I had to use unmenu to stop the array. The sad news is that as soon as I hit Stop on unmenu, it too because non-responsive. I had to use the console and Powerdown, which didn't power all the way down. So, had to issue the reboot command and it rebooted. I did not have these issues with rc11, and it first showed it ugly head in rc12a for me, but is now very bad. SF just isn't happy. @Speeding Ant - do you already know the root cause for this? Even better, do you know how to fix it? If you need syslogs or anything, let me know. I just figured given this has been a issue with so many people reporting it, you must already have figured out what the cause is. Please fix and update SF. If you are running uot of memory, then any process that is idle will be killed. I've had times when logging in would have my login session killed. (granted, I was attempting to compile something I did not have the memory for, so I knew the cause of the OOM condition) It might not be SimpleFeatures itself, but it is a symptom of memory used by one of your other add-ons.

CleanPowerDown package writes log files as part of the shutdown routine. #!/bin/bash # Start/stop/restart unRAID. if [ ${DEBUG:=0} -gt 0 ] then set -x -v fi P=${0##*/} # basename of program R=${0%%$P} # dirname of program # Set Your LOG directory here LOGDIR=/boot/logs # Set amount of syslogs you want to keep. # Number of syslogs to save in logdir LOGSAVE="10" # If the LOG directory does not exist, make it! [ ! -d ${LOGDIR} ] && mkdir -p ${LOGDIR} PATH=$PATH:/sbin:/usr/sbin:/boot/custom/bin # Alter this to NO or anything other then YES # To disable calls to these diagnostics SMARTCTL=${SMARTCTL:=YES} HDPARM=${HDPARM:=YES} # Source external file to replace anything that is defined if [ -f /etc/${P} ] then source /etc/${P} fi logger() { typeset F=${1##-t*} if [ "${F}" != "${1}" ] then F="" else F="-t${P}" fi # /usr/bin/logger -is -plocal7.info ${F} $* /usr/bin/logger -i -plocal7.info ${F} $* } diagnostic_dump() { echo "Capturing information to syslog. Please wait..." logger -tversion -s < /proc/version logger -tcmdline < /proc/cmdline logger -tmeminfo < /proc/meminfo logger -tdevices < /proc/devices logger -tinterrupts < /proc/interrupts logger -tioports < /proc/ioports logger -tdma < /proc/dma logger -tmounts < /proc/mounts logger -tdiskstats < /proc/diskstats if [ "${HDPARM}" = "YES" ] ; then ls -1 /dev/sd[a-z] /dev/hd[a-z] | while read DEVICE do hdparm -I -i ${DEVICE} done 2>&1 | logger -thdparm fi if [ "${SMARTCTL}" = "YES" ] ; then ls -1 /dev/sd[a-z] /dev/hd[a-z] | while read DEVICE do smartctl -n standby -d ata -a ${DEVICE} done 2>&1 | sed 's/\t/ /g' | logger -tsmartctl fi lspci 2>&1 | logger -tpspci lsmod 2>&1 | logger -tlsmod ifconfig eth0 2>&1 | logger -tifconfig ( ethtool eth0 ; ethtool -S eth0 ) | sed 's/\t/ /g' 2>&1 | logger -tethtool BC=/boot/config for FILE in ${BC}/*.cfg ${BC}/shares/* do BFILE=${FILE##*/} # Basename of FILE logger -t${BFILE} < ${FILE} done if [ -e /proc/mdcmd ] then echo status > /proc/mdcmd sleep 1 logger -tmdcmd < /proc/mdcmd fi unRAID_status | logger -tstatus -s } save_syslog() { TS="%Y%m%d-%H%M%S" LOGDATE=`ls -l --time-style="+${TS}" /var/log/syslog | cut -d' ' -f6` LOGNAME="${LOGDIR}/syslog-${LOGDATE}.txt" # Save only the $LOGSAVE number of current files i=0 ls -1t ${LOGDIR}/syslog*.txt | while read SYSLOG do ((i++)) if [ $i -gt ${LOGSAVE} ] then echo "Removing old syslog: ${SYSLOG}" rm -f ${SYSLOG} fi done # logger "Saving current syslog to ${LOGNAME}" echo "Saving current syslog: ${LOGNAME}" todos < /var/log/syslog > "${LOGNAME}" touch --reference=/var/log/syslog ${LOGNAME} chmod a-x ${LOGNAME} ls -l "${LOGNAME}" # Save latest syslog in a .zip archive for uploading # logger "zipping current syslog to ${LOGDIR}/syslog.zip" # only zip a new syslog.txt if syslog newer then current .zip if [ ! -x /usr/bin/zip ] then echo "zip not installed. Consider installing to automatically zip current syslog" return fi if [ /var/log/syslog -nt ${LOGDIR}/syslog.zip ] then cd /var/log # make a symlink to syslog.txt for windows viewing ln -s syslog syslog.txt rm -f ${LOGDIR}/syslog.zip # -o (set .zip time to mtime of syslog) # -l (convert lf to crlf on the fly!) zip -o -l ${LOGDIR}/syslog.zip syslog.txt rm -f syslog.txt # remove symlink chmod a-x ${LOGDIR}/syslog.zip # remove samba attributes fi } OK, so that is what is saving logs... An add-on (that many install)

The one configuration screen you have shown has a "space" in each of the disk names. That is wrong. Use "disk1" Not "Disk 1" Use all lower case for the disk names (although I'm not sure if that matters) There is no need to populate BOTH the includes and excludes. One is enough. As I said, you've not listed "disk4" Your include line is likely being ignored. (Disk 4 != disk4 )

SimpleFeatures is an alternative "skin" for the stock unRAID interface (emhttp). If emhttp crashes, it does not matter which "skin" you've installed, you cannot shut down unRAID easily. emhttp cannot be re-started on the 5.0 series of unRAID without un-mounting all the disks and removing all the mount-points. That cannot occur without stopping the array. You can't easily stop the array if you do not have emhttp. unMENU is its own web-server (written in "awk") and entirely independent. It has enough logic to shut down the server as cleanly as it can in place of emhttp. (It kiils processes, un-mounts drives, stops the array) It cannot re-start emhttp, nor administer the array. It can let you reboot.

This is incorrect. unRAID does NOT keep a "logs" directory on the flash drive. It is NOT ever kept on the flash drive unless you installed some kind of add-on to save it. unMENU has no such feature. It does not save logs to the flash drive. The system log is entirely in memory and is gone when you crash or reboot. It is in /var/log/syslg Joe L.

I've never tried it on another Linux distro but I suspect it will not work. It may work, HOWEVER when you list drives eligible for clearing it will not be able to read any of the normal unRAID config files, and therefore will may list all the drives. It is especially important to know the model/serial number of the drive you wish cleared, and its affiliated /dev/sdX device name, since you'll feel pretty darned dumb/stupid/careless if you answer "Yes" to zeroing a disk holding your ubuntu installation.

What do you have under "Settings->Share Settings" I'll bet they say disk1-3. You really should just leave those include/exclude fields blank. (I'll bet you do not have disk4 listed.)

good Turn OFF all the other PCs and media players on your LAN, I'll bet it spins down.