Activity on My Book Live Duo for no reason / cannot use drive properly

Sometime tonight my My Book Live Duo 4TB front LED started blinking as if there is a lot of drive or file activity going on. Except, there isn’t.

Went in to front end interface. Showed red exclamation, “System has restarted” with a timestamp of May 15, 2013 (10 days in the future)!

Did not get any e-mail events from the drive.

Remote access is disabled.

DLNA and iTunes are disabled.

Under “Share List,” “Media Serving” is all off for all shares.

Drive is configured as RAID1 (2TB). RAID status is “Good,” both drives also show “Good.”

I ran “Diagnostic”. It hung at 90% for 10-15 minutes, then passed.

Everything in the web interface seems to show that nothing unusual is happening. Drive status is “Good.”

I can browse the drive, and do small file transfers. Large file transfers hang after ~10-20 megs.

Tried to create and save a system report, that also looked like it hung, but it eventually saved after several minutes.

Looking at the logs, it appears that the system has started some sort of RAID data redundancy check.

I noticed that the last event in the daemon.log file is:

May  5 03:12:11 MYBOOKLIVEDUO mdadm[3918]: Rebuild20 event detected on md device /dev/md3

That is the only “Rebuild20” event in the daemon.log file.

Why would this be happening? Is this some automatic process? Is there a way to configure it? Why isn’t the status of the drive showing that this test or check is happening, since it’s adversely affecting drive performance?

Have not tried rebooting yet… I’m afraid it might cause data loss.

Here is is the daemon.log and process_list from the system log zip file.

Here are the entries from process_list that are using CPU:

www-data 31866  0.2 11.8  69824 30016 ?        S<   03:38   0:04 /usr/sbin/apache2 -k start
www-data 31859  0.3 12.3  68736 31424 ?        S<   03:37   0:04 /usr/sbin/apache2 -k start
www-data 12995  0.5 13.5  72064 34304 ?        S<   03:56   0:01 /usr/sbin/apache2 -k start
root      2899  0.8  0.0      0     0 ?        R    Apr23 136:13 [md3_raid1]
root     15901  0.8  1.2   5056  3136 ?        S<   04:01   0:00 /bin/bash /usr/local/sbin/getSystemLog.sh
www-data 31843  1.3 13.6  73088 34496 ?        S<   03:37   0:19 /usr/sbin/apache2 -k start
www-data 31886  1.4 12.3  69888 31296 ?        S<   03:38   0:20 /usr/sbin/apache2 -k start
www-data 31863  1.4 14.7  75136 37376 ?        S<   03:38   0:20 /usr/sbin/apache2 -k start
root     25413 10.6  0.0      0     0 ?        D    00:57  19:39 [md3_resync]
nobody   31640 66.7  2.8  52800  7232 ?        R<   03:33  18:47 /usr/sbin/smbd -D

It’s a daily cron job:

BIGNAS3:/etc/cron.daily# cat mdadm
#!/bin/sh
#
# cron.daily/mdadm -- daily check that MD devices are functional
#
# Copyright © 2008 Paul Slootman <paul@debian.org>
# distributed under the terms of the Artistic Licence 2.0

# As recommended by the manpage, run
# mdadm --monitor --scan --oneshot
# every day to ensure that any degraded MD devices don't go unnoticed.
# Email will go to the address specified in /etc/mdadm/mdadm.conf .
#
set -eu

MDADM=/sbin/mdadm
[-x $MDADM] || exit 0 # package may be removed but not purged

exec $MDADM --monitor --scan --oneshot

The odd notification that you received:  I have no idea.   I get those, ocassionally, too (once every few months?) and it appears that nothing actually happened.  And yes, the dates are often wrong.

You can use the linux command “uptime” to see if a restart actually did take place.

Still going, four and a half hours later.

Does not appear to be a daily job. As I mentioned, there is a “[md3_resync]” process in the log, and a “Rebuild20 event” in the daemon.log that came at 3:12 am (it’s 8:47 am here now). This is the only Rebuild20 event in the entire log.

If you look at daemon.log, the first events in there are May 15, so that may have been the date the drive was set to when it was first turned on?

TaneOrbs wrote:

If you look at daemon.log, the first events in there are May 15, so that may have been the date the drive was set to when it was first turned on? 

I don’t think so.  I got a notice yesterday that a Safepoint was created on May 31.   I haven’t used Safepoints in a LONG time (more than a year, maybe two.)  And when I looked at the server that was the “target” of the safepoint, there’s of course, nothing there.

So I know that the notification itself was errant.

The job DOES kick off every day.   But it may not actually need to do anything each day.

Here’s my log; I have the same entries in mine, scattered around.

daemon.log:Apr 7 00:58:40 BIGNAS3 mdadm[3936]: RebuildFinished event detected on md device /dev/md0
daemon.log:Apr 7 00:58:40 BIGNAS3 mdadm[3936]: RebuildStarted event detected on md device /dev/md2
daemon.log:Apr 7 00:58:50 BIGNAS3 mdadm[3936]: RebuildFinished event detected on md device /dev/md2
daemon.log:Apr 7 00:58:50 BIGNAS3 mdadm[3936]: RebuildStarted event detected on md device /dev/md3
daemon.log:Apr 7 04:35:32 BIGNAS3 mdadm[3936]: Rebuild21 event detected on md device /dev/md3
daemon.log:Apr 7 07:55:33 BIGNAS3 mdadm[3936]: Rebuild41 event detected on md device /dev/md3
daemon.log:Apr 7 11:15:34 BIGNAS3 mdadm[3936]: Rebuild61 event detected on md device /dev/md3
daemon.log:Apr 7 14:35:36 BIGNAS3 mdadm[3936]: Rebuild81 event detected on md device /dev/md3
daemon.log:Apr 7 17:43:11 BIGNAS3 mdadm[3936]: RebuildFinished event detected on md device /dev/md3
daemon.log:Apr 13 09:17:54 BIGNAS3 mdadm[4433]: RebuildStarted event detected on md device /dev/md1
daemon.log:Apr 13 09:34:34 BIGNAS3 mdadm[4433]: Rebuild54 event detected on md device /dev/md1
daemon.log:Apr 13 10:05:52 BIGNAS3 mdadm[4433]: Rebuild51 event detected on md device /dev/md1
daemon.log:Apr 13 10:21:36 BIGNAS3 mdadm[4433]: RebuildFinished event detected on md device /dev/md1
daemon.log:May 5 00:57:01 BIGNAS3 mdadm[4433]: RebuildStarted event detected on md device /dev/md1
daemon.log:May 5 01:05:04 BIGNAS3 mdadm[4433]: RebuildFinished event detected on md device /dev/md1
daemon.log:May 5 01:05:04 BIGNAS3 mdadm[4433]: RebuildStarted event detected on md device /dev/md2
daemon.log:May 5 01:06:09 BIGNAS3 mdadm[4433]: RebuildFinished event detected on md device /dev/md2
daemon.log:May 5 01:06:09 BIGNAS3 mdadm[4433]: RebuildStarted event detected on md device /dev/md3
daemon.log:May 5 06:22:51 BIGNAS3 mdadm[4433]: Rebuild20 event detected on md device /dev/md3

Well, whatever the log does or doesn’t show, it’s now been eight and a half hours and the My Book Live Duo light is still constantly flashing. It has NEVER done that before, and whatever activity this indicates is slowing down the drive.

Either it’s broken, or there’s some kind of firmware or software bug.

Will try rebooting now, hopefully I don’t lose data…

After rebooting, the light is no longer flashing and the strage/rouge behavior seems to have stopped.

I noticed in the process list, that the [md3_resync] process is no longer running. Also, this process:

nobody    8485  0.0  4.7  49856 12160 ?        S<   12:27   0:00 /usr/sbin/smbd -D

…is now using 0.0 CPU, before it was fluctuating between 60 - 100%.

Not sure if this was all caused by a hardware or software fault.

I’m dreading that this problem might continue to crop up.

smbd is a Samba process handler. The only time that should be active is if something is reading or writing via a network connection.

If that process ever does that again, you can run smbstatus command to see what it is doing.

Just got back visiting relatives.

They also have a 2 TB My Book Live Duo. I honestly thought it would be fine, but my curiosity got the best of me and I checked it, and lo and behold, when I went up to it, the light was blinking! I asked them if they knew anything about it, and they told me it had been doing that all day. I logged in to the web interface, and sure enough, it showed that the system rebooted on May 15, 2013 (10 days in the future). I asked them to check their e-mail, and they received no messages from their drive. I rebooted their drive, and the blinking activity stopped, just like it did on mine.

This leads me to believe there is some kind of strange software bug happening.