TS-EC879u-RP with FW 3.5.1.1002 Unstable

[ProTeck]

gm85,

Can you provide me the instructions for the syslog set up?

Thanks,

[sculp]

Our client has a TS-879U-RP with firmware 3.5.2 Build 1126T.

They are running VMware Esxi 5 in a production environment with multiple windows servers pointing to the QNAP using Iscsi.

We have been expieriencing the "The system was not shut down properly last time." issue and it has happened 5 times since December 13.

It has not effected our VMware Virtuals except for our exchange 2007 server running windows server 2008.

Everytime the error occurrs, the exchange mailstores dismount. The iscsi targets then needs to be remounted and the exchange services restarted before being able mount the mailstores.

This time (01-04-2012) it happened again but the mailstores have been corrupted. We were able to recover using eseutil but our client has asked RMA appliance.

QNAP support has not found anything in the logs that would cause the appliance to restart and has asked us to run a memory stress test which would need to be done after hours since the test has to be run without any services running.

We are perfoming this test this evening and hope that QNAP will be able to have a resolution.

[ProTeck]

Hi,

We Ran a memory stress test per QNAP support request. It didn't put much of a load on the memory (didn't stress it enough). Results came back fine from the test. We are currently running VMWare 4.1 in our environment.

[sculp]

I updated my QNAP support ticket so that they are aware the memory test will most likely not work, however we will still run the test to be sure. What did support say to you after you ran the memory stress tests?

[ProTeck]

Basically they stated that if it crashed again, they will have to RMA the device. As mentioned in my previous posts in this thread, I have taken about 90% of the tasks this was doing off it. It hasn't crashed since (largely due to doing nothing).

[gm85]

These steps require SSH access and some knowledge of linux systems. Of course I can't make any guarantees.

In order to start syslog, I created an autorun.sh file that would execute tasks at startup (details about how to do this are located at http://wiki.qnap.com/wiki/Running_Your_ ... at_Startup )

Since the filesystem is volitile, we have to store the logs on one of your drive volumes in order for them to survive a crash/reboot. The volumes are mounted at /share/MDx_DATA (with x being the number of the volume created.... 0 is the first volume created, 1 is the second, etc). You can see your list of volumes by issuing the df command.

Create a directory on one of your drive volumes that will store the datafiles (such as /share/MD0_DATA/qnaplogs).

Next, you will need to mount the /dev/sdx6 storage device in order to create the autorun.sh file. You can do this with the following command:

Code: Select all

mount -t ext2 /dev/sdx6 /tmp/config

this will mount the sdx6 storage device to the path /tmp/config

change to the /tmp/config directory.

create a file called autorun.sh. I use VI, but any other text editor can be used. Place the following commands in the file:

Code: Select all

#!/bin/sh

/sbin/syslogd -n -m 0 -O /share/MD0_DATA/qnaplogs/messages &
cp -rf /mnt/HDA_ROOT/.logs /share/MD0_DATA/qnaplogs/

This will do things at startup:
-Launch the syslog daemon and will direct output to /share/MD0_DATA/qnaplogs/messages (that way it'll survive a crash/reboot)
-make a copy of the qnap logs (including the kernel logs) to /share/MD0_DATA/qnaplogs/ (they will be found in the .logs directory). Since the kernel logs cycle after a certain number of entries, this will allow you to essentially see a "snapshot" of the kernel logs right after the crash/reboot.

make the autorun.sh bootable by using the following command:

Code: Select all

chmod a+x autorun.sh

Reboot your qnap. This will launch the syslog utility. If you can't reboot at this time, you can execute ./autorun.sh , however I don't know if syslogd will continue to run after you log out since it was executed during your SSH session. On the safe side, I used the screen command, executed ./autorun.sh, detatched (ctrl+a, d) then logged out.

If the qnap crashes, the log files will be available in /share/MD0_DATA/qnaplogs/. a copy of the kernel logs will also be there from boot time (which should contain the cause of the crash as well) if it happens overnight or you can't access the qnap in time before the entries in the logs cycle.

Also, once it crashes, don't forget to remove the autorun.sh file at a later date, otherwise these log files will continue to grow and grow.

Hope this helps

[StarrCompany]

Do you guys have write caching enabled ?

System Administration > Hardware

[serverunleashed]

I am experiencing a similar stability problem with the 879.

We are utilizing the unit in a Hyper-V cluster, and have experienced 3 qnap crashes in the last 30 days.

Previous crash occurred with firmware 3.5.1, but now have firmware version: 3.5.2 Build 1126T installed and the same problem happened again tonight.

SUPPORT????? HELP!!!!!!!!!

[P3R]

SUPPORT????? HELP!!!!!!!!!

This is how you contact Qnap support.
'

[ProTeck]

For us, Write Cache is disabled. We do this step during the initial configuration. I am wondering though, even if it is turned off in the GUI, could it be enabled at the CLI level? If so, How would I go about finding that file?

[ProTeck]

Seems like quite a few people are having similar issues that happened to us. Is QNAP working on resolving the issue? If it is the something related to hardware other than the HDD, is QNAP going to replace the systems? Again, I cannot trust our device. Our Service Level Agreement services are extremely high and cannot afford prolonged downtime.

[gm85]

Our system crashed again this weekend. Checked the log files and there are no Software/OS Indications that led to the cause of the crash... almost like if the reset button was pushed.

Contacted QNAP and they provided me with a BIOS update. Going to perform a scheduled shutdown tonight and apply the update. So far this has happened every weekend for the past 3 weeks, so hopefully this weekend will be an indication if the BIOS fix is successful or not.

[StarrCompany]

We are having the issue as well - we did have write caching enabled and we have since disabled but to early to tell if its solved it - I some what doubt it based on the posts above

[StarrCompany]

I did manage to grab a screenshot whilst QNAP were looking at our TS-879 does show scsi errors and a bus error - im not 100% sure what im looking at but thought I would put it on this thread.

[StarrCompany]

Our QNAP TS-879 just rebooted - this is now unacceptable - we need a fix or at least a response from qnap - i will be emailing qnap direct this is disgraceful the product is not fit for purpose and I look forward to someone from QNAP telling me otherwise.