As indicated in the sleep discussion thread today, I may have used the wrong values when using the cp command. This may work (note haven’t tried it yet though):
cp /var/www/rest-api/config/dynamicconfig.ini /tmp
after this update, i am no longer recieving email notifications from the nas …
After updating to this firmware im no longer able to use crontab to start/stop services.
Anybody has this problem?
I am having exactly the same problem that @zfilipovic mentioned in this thread. The latest update killed my remote FTP access, everything else working fine. Has anyone been able to find a solution that doesn’t involve rolling back?
Thanks!
Just to confirm. Have you checked the My Cloud IP address and ensure the port forwarding on the router is using the same IP address to forward port 21 to the My Cloud? Have you checked to ensure your broadband IP address hasn’t changed? Have you checked local network FTP access to ensure it’s working?
Edit to add: Just tested remote FTP access on my single bay v04.05.00-320 My Cloud and remote FTP access is working fine.
One additional item to check for is if your broadband provider is or has started blocking inbound connections like FTP to your local network. Websites like http://canyouseeme.org/ can be used to check if one’s port forwarding is working properly and if one’s broadband provider is potentially blocking access.
Ok so it is all solved. I forwarded in the router the FTP ports (21-22) and now it is all good. What I can’t remember is whether I had not forwarded them before, or if somehow the setting got deleted in the router.
Thanks anyway!
Generally one has to setup port forwarding of port 21 with the local network router otherwise FTP traffic doesn’t get through the router’s firewall from the internet.
Hello to everyone!
I recently upgraded my My Cloud to firmware version 04.05.00-320 (after some years of staying with 4.00.01-623). The upgrade process was a pain: the first reboot (solid white led) took about 8 hours to complete and the unit required around other 8 hours before being accessible again (with either SSH, Samba, Web UI or such) after the led turned solid blue. During these 16 hours, the internal hard disk was being scanned thoroughly…
Apart from this (unacceptable) behaviour, it is now operating perfectly fine. However every day a new “du” process on all the shares in /shares/ is started. Since I have at least one share which is crowded with data, this process lasts for dozen hours. And when it finishes, it seems like a new scan is started from scratch again and again. The result is that my disk is continuously spinning and scanning all the data.
The process is identified like this in ps:
root 17707 2.6 12.2 44288 28480 ? DN Apr12 29:38 du -sbL /shares/BackupCustom
And “pstree -sp” on that PID reveals:
init(1)---monitorio.sh(26883)---xargs(17692)---getShareSize.sh(17703)---du(17707)
Looking quickly at monitorio.sh, and reading some discussions here, I understand it’s a script from WD that monitors disk activity and puts the disk into standby when needed (or at least it’s supposed to do that). It also starts some share size calculation processes whenever data utilisation on disk has changed with a threshold of 1 GB (if I understand it correctly). However, even if I do not change any data on the disk, I see a new du process like the above one started EVERY DAY.
I do not care about the sleep issue too much (I have too many services running on my unit for it to be put to sleep), but I don’t want to kill the disk just because it’s performing useless du tasks continuously.
Does anyone has any deeper inside on this? And, by the way, what is such “tally daemon” mentioned in the monitorio.sh script (which is however missing in my My Cloud device)? I could not find any useful information on the internet.
Thanks in advance.
You must have a lot of files for the du process to take so long to run. The monitorio.sh script calls getShareSize.sh twice once for directories and once for symbolic links.
time find /shares/ -maxdepth 1 -mindepth 1 -type d -not -name “.*” -print0 | xargs -0 -I {} getShareSize.sh {}
time find /shares/ -maxdepth 1 -mindepth 1 -type l -not -name “.*” -print0 | xargs -0 -I {} getShareSize.sh {}
These two commands will do what monitorio.sh does. But will display the time it took for them to run. On my system with 3.5TB of video files these commands run in a few seconds.
If you google /usr/bin/daemon you will find information explaining daemon.
Yes, as I said I have a lot of files in one of the subfolders of /shares. In total there are 4 or 5 subfolders in /shares/, one of which is the /shares/BackupCustom folder mentioned in my previous post.
So what?
The problem is not that it takes a lot of time, the problem is that, once it finishes, it starts again to do the same over and over again, every day a brand new du process on the same /shares/BackupCustom folder is run.
I know what a daemon is, I don’t know what “tally daemon” (mentioned in monitorio.sh) is about, and why it is missing from the My Cloud. It seems like its presence would avoid the need to call getShareSize.sh…
Would you please time those two commands? Lets see how long it really takes.
I need to redirect the output to some file, because I can’t keep a ssh shell open during the whole process. And this will cause a second du process running concurrently.
Anyway, just run now (grep on ps output):
root 17707 2.4 12.9 64960 30016 ? DN Apr12 39:53 du -sbL /shares/BackupCustom
The process is the same one shown today at 10.08, it’s still running. It started on April 12, so it’s running from AT LEAST 18,5 hours (it’s 18:30 here right now).
I’m probably missing the point about knowing exactly how long it takes to run. The problem is that it’s started over and over again.
Have you done a reset since upgrading the firmware? Upgrades do sometimes cause odd residual behaviour, that is often sorted by a reset.
It should not take 18 hours to do a du command. Secondly for it to start over it need to complete. I just ran a test on by Linux system. One of the filesystems has 1,506,350 files. A du -sbL takes less than 2 minutes.
I would be suspicious that the du process is hung. A few simple thinks you could do.
kill the du process. Then sh /etc/r2.d/S18monitorio stop
cd to / Run the “time du -sbl /shares” command.
As an aside. I’ve never seen a PPID of 2.4
Did you modify the firmware of your My Cloud, either pre or post firmware upgrade? Have you compiled your own firmware or added packages to your firmware? I’ve seen you posted to a different thread on building packages for firmware.
A firmware update, reboot and rescan should not take 8 hours unless there is something wrong with the firmware or you have a huge number of files and the My Cloud is having trouble scanning them due to number or type of files.
No, I did not perform a reset. However, all is working fine, it’s just that monitorio.sh script that is behaving strangely, so I think the problem is well delimited. After issuing a “service monitorio stop” it does not operate any more, of course. Does anyone know if that service is actually used for anything else rather than determining if the drive should go into sleep mode?
2.4 is %CPU.
Yesterday I ran again ps and this is what I saw, which confirms that the du process started by monitorio has been re-run one day after:
root 30586 2.6 12.5 43776 29056 ? DN Apr13 29:03 du -sbL /shares/BackupCustom
As you can see, new PID and new “time started” for this process, one day after the previous one.
pstree reveals:
init(1)---monitorio.sh(26883)---xargs(30571)---getShareSize.sh(30582)---du(30586)
So, once again started by monitorio.sh, same process instance for it, new xargs invocation.
I then stopped it with “service monitorio stop” and ran some statistics.
I have 4 internal shared folders in /shares, with the following contents:
Download: 596 files, 32 folders
Public: 141,049 files, 11,717 folders
System: 35,930 files, 146 folders
BackupCustom: 15,457,196 files, 2,732,265 folders
As you can see, the last one is way bigger than yours and it’s the one that is taking a lot of time to scan.
I have also started the two time commands you suggested earlier, they are still running, when they’ve finished I’ll post here the results.
I always used the original firmware, just cross-compiled some additional packages and installed it in the documented way. They are all user-space programs. On the last-but-one firmware version I was using, I had also fixed a problem with Samba lock files which was causing periodic crashes of the unit because of tmpfs being filled up with Samba logs/lock files. I see that this problem has been fixed by Western Digital in the latest firmware version. Anyway, I verified that any firmware upgrade wipes almost the whole /, including /usr, /root, /etc (only /var is kept among firmware upgrades), so it’s quite a “cleanup and restart from scratch” operation. In fact, after each firmware upgrade I have to re-install and re-configure all my additional packages.
It’s already the third firmware upgrade I perform with this technique and I can’t remember this phenomenon happening before.
Please also note that this behaviour started to happen just after the firmware upgrade, before adding any additional cross-compiled packages, so it’s not caused by them.
A firmware update/reboot should not take 8 hours, you’re right, but if WD slows down the whole process by performing a full rescan of the shares folder which prevents the unit from being usable any more for almost 16 hours, that’s a bad engineering by WD, because there’s no sane reason for which I should not have a lot of files under /shares, especially if we’re talking about devices which can hold terabytes of data…
How about also providing a complete ps command and show us the command you used. Yes you have over ten times the files that I have. But it makes no sense that the du takes so long to run.
The monitorio script sleeps while the disk is in standby. When it wakes up it it logs the standby time. Changes the led to solid blue. Walks thru the /proc/diskstats file looking for diskio. Then if starts a 60 second sleep loop looking at /proc/diskstats checking for no I/O. If there has been any writes to the data volume. it will do some checking which includes the du comand. After monitorio wakes up 10 times with no disk I/O it will put the disk to sleep and start over waiting for the disk to exit standby mode.
When you stopped the monitorio process did the du process stop?
