The unofficial gen2 definitive sleep

My Cloud OS 3 Personal & Network Attached Storage My Cloud
1

So my drive has been ticking for the last week or so making me think that it is still doing its scans and it seems that this slow ticking is just another unknown WD process but it made me do a final look over on how I can, once and for all, force a gen2 cloud to sleep.

I know that all of this is not new to everyone here but I found that if you do kill the scan processes after you turn on Cloud Access, you can effectively keep them off even with remote cloud access until you reboot the cloud or when you toggle Cloud access off and then on. You will still have remote cloud access without the scans that takes weeks to complete.

Thus after turning on Cloud Access… type or put them all in a script and run

/etc/init.d/wdphotodbmergerd stop
/etc/init.d/wdmcserverd stop
killall crond

With cron turned off your cloud won’t wake up at various hours during the day. You will need to redo the commands if you restart cloud access.

I’ve noticed that if you do copy new data over to the cloud, the cloud will wake up more frequently and if I remember correctly this is due to monitorio.sh noticing the change in your HD size and attempts to invoke the scans.

Anyways, the above 3 commands will provide your cloud a better night sleep even if your cloud has completed its scans. I’ve had the cron off for a better part of a year without any side effects and you can reboot the drive to restart the corn monthly to rotate the logs, clean out any tmp files and so on.

I’ll get to the bottom of this ticking as I’m fairly sure that it is a service that needs killing. Now that my backup non remote access cloud is exhibiting the same symptoms of clicking, I am just annoyed at WD for adding another level of unnecessary irritation.

2

Is monitorio.sh running? I thought that I noticed it was not running when I had my Gen2. I was looking becasue I couldn’t find the wake entries in the log.

RAC

3

I have no idea RAC and I don’t see it listed in ps -ALL, but the sleep actions (since there is no hardware sleep) are that of “monitorio.sh” which uses hdparm to spin down the drive leaving the mobo running.

As to the logging, I think WD has redirected all log entries to null which was one of the factors that kept the gen1 drive awake. In gen2, even ssh’ing onto the cloud doesn’t even spin up the hard drive as everything is now running on the RamDrive.

I did find monitorio.sh in usr/local/sbin/monitorio.sh and I don’t think it has changed much or any (printing it out now as I am typing this post up).

The logic of “Scan the drive if changed otherwise sleep” is incongruent A better logic would be the scans should be scheduled event and they can store the drive parameters from the last scan and compare it with the current parameters to see if there is a size change to continue the scanning.

Monitorio.sh should only monitor the sleep countdown and put the drive to sleep if there is no drive activity.

4

Because the monitorio.sh is not running. Some other process must be looking at drive activity. The gen1 does not redirect log entries to null. If it did then the sleep script would not work. As for scanning when a new file is added. There is a notify function in Linux. The DNS-323 uses the notify feature. When a file is added to one of the folders that is being watched. The process watching gets a notification that file x has been added. No need to scan the entire disk to find the new file.
You might look into the atop process. It could be causing disk activity. I know on the gen1 if you kill the atop process. It starts back up from a cron job. Before atop was added to the system. My gen1 would sleep up to 23 plus hours. After atop it sleeps at most 5 hours or so.

RAC

5

seriously Rac, you really have to get your own gen2 cloud and create your own hypothesis and solution post.

You are mixing a bunch of summaries, logic and conclusions together to throw me into another wild goose chase.

Perhaps monitorio.sh is not running under the name monitorio.sh but something very very similar as you say, is definitely is. WD does not re-write everything but instead they move everything and re-fit carefully into a slightly newer OS, this is true from their WD live to the first gen1 Cloud, to OS3 and finally to the Gen2 Cloud. Every new system is a single iteration of the old. They change the names but they cannot change the function.

That “some other process” must be looking at drive activity is an iteration of monitorio.sh because there are no other sleep methods that they employ. Along with that employment of hdparm to shut down the hard drive, they actually turn on and off the scans to … yup… scan the whole hard disk to see where the changes are.

Which is true because I just came from the gen1 but, now listen carefully, because a lot of the logging and even the sleep and wake output logs, can cause the drive to wake immediately because it is a log output. This was the reason that I stuck in bunch of sync at the end of monitorio.sh just to flush out the log writing.

The gen2 does suppress most if not all log output, which is a new feature to gen2, which is why the messages of monitorio.sh does not show up on user.log because it gets redirected to null. Really… but if you don’t believe me, go get a gen2 and tell me something different.

Now you are talking about your sleep script which of course won’t work because it is just a re-formatter of user.log. Yup if gen1 had output to null, then there won’t be any wake times output to user.log. Don’t confuse us with your sleep and the WD sleep.

Yup, you sleep script won’t work on gen2 because no wake times are written to user.log.

It all sounds great and logical but in gen1, monitorio.sh does not use such a feature. It just checks if the hard drive changes by a function called file_tally() & which is a function that runs in the background. Since it is embedded within the script, you won’t see a name file_tally() in ps -ALL.

There is no hardware notifies that tells you what has changed on a hard drive. A software notify has to set up a notification file list to monitor, then compares the entries to a known list.

For the most part, if you are scanning for changes, it does a scan in software whether it is a linux command or a WD function.

Ahh yes the atop process. So when I got upset with my cloud this weekend, I stopped everything including atop and nothing stopped the incessant clicking, but I’ll try again with stopping all the services once again just to find the culprit.

atop(1) - Linux man page

Name

atop - AT Computing’s System & Process Monitor
Synopsis

Interactive usage:
atop [-g|-m|-d|-n|-u|-p|-s|-c|-v|-o] [-C|-M|-D|-N|-A] [-af1x] [-L linelen] [-Plabel[,label]…] [ interval [ samples ]]

Writing and reading raw logfiles:

atop -w rawfile [-a] [-S] [ interval [ samples ]]
atop -r [ rawfile ] [-b hh:mm ] [-e hh:mm ] [-g|-m|-d|-n|-u|-p|-s|-c|-v|-o] [-C|-M|-D|-N|-A] [-f1x] [-L linelen] [-Plabel[,label]…]

6

Ok I will stop replying after this response. The monitorio.sh script looks at the file /proc/diskstats.
This file is updated everytime a disk I/O is done.

RAC

7

buy and keep the gen2 drive and you can conjecture and hypothesize as much as you want by showing us your findings. By the way, I did not have to stop ATOP on gen1 to get 50 hours of sleep.

yes it does… to see the following bits … 6 and 10 I think to see if sectors are read and written which then triggers MEDIACRAWLER_REWALK if the drive is wakened. No file list here telling us which file has been updated.

What: /proc/diskstats
Date: February 2008
Contact: Jerome Marchand jmarchan@redhat.com
Description:
The /proc/diskstats file displays the I/O statistics
of block devices. Each line contains the following 14
fields:
1 - major number
2 - minor mumber
3 - device name
4 - reads completed successfully
5 - reads merged
6 - sectors read
7 - time spent reading (ms)
8 - writes completed
9 - writes merged
10 - sectors written
11 - time spent writing (ms)
12 - I/Os currently in progress
13 - time spent doing I/Os (ms)
14 - weighted time spent doing I/Os (ms)
For more details refer to Documentation/iostats.txt

8

So Rac, after you made me look at Monitorio.sh, I think I know what is making that slow tick sound whenever you load up a cloud with data. It has to be file_tally() function that is spawned within Monitorio.sh. It is a very low priority background process and as its name says, its job is to tally up the file sizes I think to report that indeed the user has added some files, so please go ahead and scan me.

Just a hypothesis… you may proceed to jump to conclusions if you like…

9

I don’t think monitorio.sh is run. Remember monitorio.sh is designed to always run. It sleeps for 60 seconds and wakes up does its checks and then goes back to sleep.

RAC

I’ll bet you could rename /usr/local/sbin/monitorio.sh to /usr/local/sbin/monitorio.shh
and the system will still work. A reboot will put the file back.

10

well yes of course, all the files are there for show and nothing you do will affect the running of the system, except if you do a killall crond :stuck_out_tongue:

but I think what we are looking at is actually the ram drive and if you rename or delete a file (which I did do), when you reboot, all the files are extracted from a packed system file and monitorio.sh will be right back where it is or was.

But definitely a monitorio.sh look alike is running as well as a file_tally() & <=== background running is running. That slow tick is a dead giveaway…

anyways… neither of us knows for sure unless I can find which process is monitorio.sh :slight_smile: and if I can kill xxxx <==== pid then I can run my own version of monitorio.sh which doesn’t have file_tally() & then I can get rid of that annoying tick.

Now what I said does come from experience because I did commented the actual file_tally () function out on the old gen1 cloud and thereby rendering monitorio.sh on the old cloud to become more benign, which was why my old cloud was so much more usable. I just need to replace the monitorio look-alike program on gen2 with my version. wish me luck… or you could buy a gen2 cloud again and give me a helping hand to either prove me wrong or right, I don’t care, but just fix this so it doesn’t tick :frowning:

11

Additional information. The /usr/local/config folder which is on sda7 is where the gen2 saves its changes that you make from the dashboard. It also has three of the logs. The /usr/local/modules
is a mount point for the /boot/boot/image.cfs file. The boot folder is the mount point for sda3. sda3 contains the data that is reloaded on reboot. Then the /usr/local/config information is used to setup the gen2 with your personnel changes.

RAC

12

I have no idea what to do with that additional information… I need some subtrational information to balance it out!..

however I do see monitorio.sh in /usr/local/modules/localsbin <== are you saying that I can replace monitorio.sh here and it would copy itself into the usr/local/sbin on reboot?

My new cloud is coming on Friday and I’m not too sure what I’m going to do with it?

  1. take it back to costco and return it un-opened
  2. open it and play with it, tweaking it until it breaks and then take it back to costco
  3. copy all data to it and use it as my main drive, return the other one.
  4. keep it and give it as a christmas gift to RAC… hmmmm never mind … invalid random thought… RAC is happy with what he has got and that is a gen1 cloud.
13

The monitorio.sh in /usr/local/sbin is a symbolic link to /usr/local/modules/localsbin/monitorio.sh.
So removing monitorio.sh in /usr/local/sbin will be relinked on reboot. /usr/local/modules is the image.cfs file.

RAC

14

Another interesting fact. Check out /var/spool/cron/crontabs/root file. It shows that sysinfo_update.sh script is run every minute. It also shows a couple other jobs that run every 10 minutes or every 15 minutes.

RAC

PS check out /usr/local/config/config.xml file it generates some of the cron jobs.

15

That is not what I asked. I said

the other way around… replace it in the /usr/local/modules/localsbin and thereby it should have the replaced monitorio.sh on boot up.

Anyways… did some searching on the net for you… and found something that will help you on your research. <== click on link

Just need a detail step by step procedure on replacing monitorio.sh and I’ll be ecstatic :stuck_out_tongue:

Thanks RAC

16

I’m not sure why you want to change monitorio.sh it does not run any more. I only told you about removeing it so that you could see that it does not get called any more. Changing it in /usr/local/module could brick the device. Changing it in /usr/local/sbin at the most would cause a hang or some type of system error. Which a reboot would fix.

RAC

17

I don’t believe you :stuck_out_tongue: from what basis are you telling me this? not seeing it under the name monitorio.sh doesn’t mean it isn’t running. If I included the script under “nonane.sh” it will show up as nonane.sh running and not monitorio.sh.

anyways, I say that it is in fact running probably under the guise of “init” which is the startup script for everything.

anyways, think about this… why are they including a script that doesn’t run anymore? if they are so intent on saving space? thus I conclude that it is running… and it has been included in one large run “init” script at the startup. To remove it from the init running or modifying it will allow us to delete or modify the file_tally() function so that it doesn’t scan the hard drive.

Removing it doesn’t prove that it isn’t running. In fact it is running, but deleting it just removes it temporarily from the hard drive and restores itself at startup.

why? this is a script, not a library or DLL. It doesn’t reload itself once it starts running. It remains in memory and runs from memory once a script starts until you kill it. Once you kill it, then if you start the script again, it can be any copy of monitorio.sh that you want, even from a share directory. So if I can find the monitorio.sh PID then killing it on the command line will be the first step in running my own copy.

Trust my knowledge as it is older than you.

18

So Rac, because of you, I’ll be using my new Cloud that is being shipped in from Costco as my new deconstructive drive. I’ll do my best to see if I can find the sleep code that is running under busybox just so I can get the last word on this.

Also, I will be working on my rsync between cloud drives so I can get this sync’ing once and for all working.

I am tired of having to sync my drives every month.

Not sure if I can make an app out of this… but I’ll give it a shot. It has been years since I’ve worked on linux scripts, apps and code.

I don’t like it, but yup, because of you… I’ll put some effort into this so we have some definitive answer rather than guesses.

19

Not sure why you want to put yourself through the pain of a new generation. :smiley: When my V1 dies, I’m buying a Synology.

20

A little more info. There is a disk_monitor.sh script in /usr/local/modules. It appears to be a replacement for monitorio.sh. But disk_monitorio.sh does not put any entries in the user.log. It also does not call hdparm -y. But if you grep hdparm /usr/local/modules/vft you will see that it
calls hdparm -y for /dev/sda and /dev/sdb. But vft is not running.