Sometimes I really wish I could buy something and simply be happy with it 
However my latest problem with the WD Cloud is that the device would wake up at random intervals all through the night. Some as short as 2 minutes, 6 minutes, 20 minutes and the longest sleep is 70 minutes. However this sleep depravation will have to wait for another post as one of my old problem came back.
The device has been running for about 2 weeks now, so to ensure that my sleep depravation wasn’t due to some leftover flag that was left in tmp, I decided to reboot with the USB drive attached.
After the regular appropriate time of holding my breath, the Web UI came back up, mapped out the drive and even SSH into the device. Everything seems normal. Of course after a reboot, there was a large number of wdnotifier and wddispatcher running. This is normal until it was not 
then it happend…
I got no response from the device, although you can still hear it thrashing… clickity clackity… blue light on, green light in the back blinking… No web response, my mapped drive showed no files, SSH hunged. Closed the window and attempted another SSH into the device. No response…
Well as seasoned WD forum members, everyone knows what to do? right?
so I pulled the plug… yup… probably left a few blocks of unlinked data on the disk… and started up the device
Solution:
kept hitting SSH to connect (while the drive is still booting) until I do connect…
then type
killall wddispatcher
killall wdnotifier
(remember that I DO NOT have wdmcserverd and wdphotodbmergerd running)
to keep from wdmcserverd from running and you can always start it up later
killall wdmcserver
killall wdphotodbmerger
Everything settled down. No more clicking and clacking of the hard drive. The connection stayed up, I could access the USB drive normally. Everything came up roses.
Not happy
I was not happy though. I had thought that all my problems were solved without having to resort to SSH’ing into the device and killing off small innocent processes. So as I sat in my thinking throne room, I thought… well perhaps I should just let the device thrash itself out…
Detaching USB drive after process killed
With that determined, I decided that I better remove the USB drive which contains a full backup/mirror of my files, just in case the thrashing carries over to the USB drive.
However after waiting at the Web/UI for a long undermined time, for the USB device to be found, I knew that I had to start up the two processes that I just killed in order to get the little eject symbol for the USB drive.
thus
/etc/init.d/wddispatcherd start
/etc/init.d/wdnotifierd start
Then after a short while, the USB icon will light up as well as the button to eject the USB. Once you have done that and waiting for the Web message to respond back to the main menu, detach the USB drive cable.
You will note, that despite the fact wddispatcher and wdnotifier are running, they no longer causes any further problem with your device. It just seems to be at the initial startup that caused some kind of lockup followed by a disconnection.
Rebooted with no lockups
So anyways, I rebooted using the Web utility reboot and the device came back on. I mapped out the drive, I SSH’ed into the drive… and waited for the device to disconnect itself…
and waited
and waited…
So I started up a movie streaming from the device to my Mac and went for an hour long exercise… and came back to find:
The movie was still running
The drive was still mapped and connected
my SSH connection was still active…
wdnotifier and wddispatcher are still running from the initial bootup without having to kill it and restart it.
(note: wdcmserverd and wdphotodbmergerd have been stopped permanently from prior modifications)
So this is a clean boot with no intervention.
The only difference was tNO USB drive connected.
Connecting the USB drive after bootup
Since the drive has been running for an hour with no services stopped…
I decided that it was time to test out my new theory of plugging in the USB drive which will then lock and disconnect the device. So I connected the USB drive…
and waited…
and waited…
Both devices stayed up… mapped and running with no problems… no interventions
Sooo…
Summarization of what just happened
-
don’t reboot with the USB drive connected
-
if you do reboot with the USB drive connected, immediately SSH into the device and kill the processes before they lock your device, then start them up to disconnect your USB. then restart to ensure a clean boot.
-
it seems that you should always wait an indeterminable time before connecting your USB drive, lets say 5 minutes?
-
if you still get lockup with or without your USB drive attached, you can wait until the drive comes back (since I never had the patience to wait I’ll need someone else to tell me if the drive ever comes back) or you can SSH into the device and kill the two process. I have been running for over two weeks without the two processes.
I do not like the fact that once it locks up there is no way of shutting down the drives normally. The fact that I pull the plug means that the drives will need fsck, equivalent to chkdisk on the pc. Thus it was important to me that I could boot up without having to kill any processes. That all tasks completes as the developers intended. Flags gets cleared, fsck gets runned.
So this should the last word on this problem. Good luck and godspeed… now back to the sleeping problem
edit: so after the reboot, without killing or restarting any process, the drive is sleeping quietly on the shelf. Looks like I don’t need to research this problem any further.
