The Guide to Cloud Services as defined by the User Community

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

The way that we figure what services we don’t need is by stopping them one by one until the cloud no longer responds and then we reboot and continue stopping the other services until we figure the minimal number services that the machine will need to work and vice versa like when we find that we can no longer connect to the drive, we start up the services one by one until such service like SMB starts to work again.

Of course there is the other more intellectual method such as Google but we tend to fall asleep on the technical terms such as “procps” which is the package that has a bunch of small useful utilities that give information about processes using the /proc filesystem. When we wake up we go back to simply shutting them down one by one until the machine doesn’t work.

I really think it is funny that the WD forums are community based rather than the Tech guys from WD answering our questions. It is the blind leading the blind, or perhaps some of us are more near sighted or far-sighted than blind but nevertheless none of us know for sure why the customers of a product are trying to solve a problem other than WD saving money on tech support.

So I thought maybe we should start up a thread that discovers what a service does, document it and then we can sticky it at the top of this User Community Forum. 

So all the following files has the following command structure

/etc/init.d/monitorio stop     <=== to stop the services

/etc/init.d/monitorio status  <=== to inquire whether the services is running or stopped

/etc/init.d/monitorio restart  <=== restart by performing a stop and start

/etc/init.d/monitorio start     <=== starts up the service.

monitorio links to the monitorio script in 

/usr/local/sbin/monitorio.sh of which you can edit and modify than restart the script using the above command.

This is the same for samba which is the SMB that Rac was talking about…

/etc/init.d/samba stop

Here we go, lets list out all the services that we can stop and find out what they do… or google it and come up with a nice succinct description of the service. However I want none of that circular descriptive that says something like 

ramlog handles all the ram logs and stops all the rams from logging.

The first thing I did was to go to the /etc/init.d directory and do a “ls -a1” and here are all the /etc/init.d scripts that can be started, re-started and stopped, and if you were like me, you would say…

hey there is a README at the top of the list…

.depend.boot

.depend.start

.depend.stop

.legacy-bootordering

README

apache2

bootlogs

bootmisc.sh

checkfs.sh

checkroot-bootclean.sh

checkroot.sh

commgrd

cron

halt

hdparm

hostname.sh

hwclock.sh

ifplugd

itunes

killprocs

kmod

lltd

mDNSResponder

mdadm

mdadm-raid

monitorTemperature

monitorio

motd

mountDataVolume.sh

mountall-bootclean.sh

mountall.sh

mountdevsubfs.sh

mountkernfs.sh

mountnfs-bootclean.sh

mountnfs.sh

mtab.sh

netatalk

networking

nfs-common

nfs-kernel-server

nspt

ntpdate

openvpn

pfe_init

procps

purgelogs.sh

ramlog

rc

rc.local

rcS

reboot

reset_button_mon

restoreSettings.sh

rmnologin

rpcbind

rsync

rsyslog

samba

saveclock.sh

sendsigs

single

skeleton

smartd

smartmontools

ssh

sudo

sysstat

twonky

udev

udev-mtab

ufsd

umountfs

umountnfs.sh

umountroot

upnp_nas

urandom

vsftpd

wdAdminEntry

wdAdminFinalize

wdAppEntry

wdAppFinalize

wdAutoMount

wdEmergencyEntry

wdEmergencyFinalize

wdInitEntry

wdInitFinalize

wdPreBoot.sh

wdVftEntry

wdVftFinalize

wddispatcherd

wdmcserverd

wdnotifierd

wdphotodbmergerd

WDMyCloud:/etc/init.d# cat README

Configuration of System V init under Debian GNU/Linux

Most Unix versions have a file here that describes how the scripts

in this directory work, and how the links in the /etc/rc?.d/ directories

influence system startup/shutdown.

For Debian, this information is contained in the policy manual, chapter 

“System run levels and init.d scripts”.  The Debian Policy Manual is 

available at:

    http://www.debian.org/doc/debian-policy/#contents

The Debian Policy Manual is also available in the Debian package

“debian-policy”.  When this package is installed, the policy manual can be

found in directory /usr/share/doc/debian-policy. If you have a browser

installed you can probably read it at

    file://localhost/usr/share/doc/debian-policy/

Some more detailed information can also be found in the files in the

/usr/share/doc/sysv-rc directory.

Debian Policy dictates that /etc/init.d/*.sh scripts must work properly

when sourced.  The following additional rules apply:

* /etc/init.d/*.sh scripts must not rely for their correct functioning

  on their being sourced rather than executed.  That is, they must work

  properly when executed too. They must include “#!/bin/sh” at the top.

  This is useful when running scripts in parallel.

* /etc/init.d/*.sh scripts must conform to the rules for sh scripts as

  spelled out in the Debian policy section entitled “Scripts” (§10.4).

Use the update-rc.d command to create symbolic links in the /etc/rc?.d

as appropriate. See that man page for more details.

All init.d scripts are expected to have a LSB style header documenting

dependencies and default runlevel settings.  The header look like this

(not all fields are required):

BEGIN INIT INFO

Provides:          skeleton

Required-Start:    $remote_fs $syslog

Required-Stop:     $remote_fs $syslog

Should-Start:      $portmap

Should-Stop:       $portmap

X-Start-Before:    nis

X-Stop-After:      nis

Default-Start:     2 3 4 5

Default-Stop:      0 1 6

X-Interactive:     true

Short-Description: Example initscript

Description:       This file should be used to construct scripts to be

#                    placed in /etc/init.d.

END INIT INFO

More information on the format is available from insserv(8).  This

information is used to dynamicaly assign sequence numbers to the

boot scripts and to run the scripts in parallel during the boot.

See also /usr/share/doc/insserv/README.Debian.

 

So lets begin defining them. I’ll leave it empty for now and as user’s contribute their definition of what that services does or perhaps the consequences, such as the device rebooted or died after I stopped the service: warning don’t do that…

2

 I really think it is funny that the WD forums are community based rather than the Tech guys from WD answering our questions. It is the blind leading the blind

I fear that ‘the Tech guys from WD’ are equally blind…

Come on ‘WD Tech guys’: prove me wrong. Explain what the services do, and which are essential, and which are ‘fluff’ and can be stopped, if the user doesn’t want that service.

3

I’ll begin with monitorio, one that I know very well. You don’t have to get into details as I have, but if you have a general idea of how it works, or even its general function (right or wrong), if wrong everyone will laugh at you and correct you; no big deal.

Monitorio

The config file is in /etc/standby.conf which has 

standby_enable=disabled or enabled

standby_time=10

monitorio is the heart of your sleep scripts. Your cloud device doesn’t actual sleep as it is always on, consuming (I think according to the specs) 5W of power when the hard drive isn’t spinning. If the hard drive is spinning, it will use 15W of power. Now compare this to a small PC that will consume up to 200w to 500w of power per hour. I use to build servers that had a stack of hard drives sitting under my desk; it was my heater during the winter months.

Anyways monitorio starts and stops the monitorio.sh script located in your /usr/local/sbin.

The script is an infinite loop type script that never ends or exit. It simply loops forever once it is started.

It has two infinite loops, one main outer loop and two smaller inner loops

while :; do   <==== main outer loop that loops all the script below forever until the cows come home or until the device is off

    ==== tiny standby exit loop ====     

    wait until disk exits standby by checking hdparm -C 

       ||

       ||

   ==== tiny wait for sleep timer loop ===

    wait for a countup till 10 retrieved from the file /etc/standby.conf

        sleep 60  <=== yes it stays sleeping for 60 seconds

        check if the disk has been access if not countdown - 1

        if disk has been access, reset countup to 1

   exit loop when countup = standby sleepcount which is 10

   put drive to sleep using hdparm -y

   go back to the top loop and wait until the hard drive wakes up

There are some other programming in monitorio that checks if you have added any files to the drive, if so a MEDIACRAWLER_REWALK file is created in tmp indicating that the scan program should check all the million jpgs, music, movies for changes. Crazy I tell you…

So if the WD programming team is reading this… The proper way to implement thumbnails and perhaps indexes is twofolds.

Always use the concept of cache; in other words never thumbnail the entire drive, only thumnail what is needed and most frequently access. Same as indexing. 

First thumbnails. Should be created when the program that needs them or displays them such as the Cloud App reading the directory to be displayed on the iPad should then check a main (single hidden cache folder on the drive) whether or not we have a thumbnail available for this file in cache, if not then create one immediately (but do list the file on the iPad first with no thumbnail) then when the thumbnail is ready, indicate to the iPad that the thumbnail is ready and should refresh with thumbnail.

Indexing is used to gain quick access to files. One method is user speciafied which means allowing the user to start up a job that indexes to optimize file location.

Second method, indexing when in use. If a user is currently browsing a directory, start up a process that does a directory read ahead and build an index structure cache. When refreshing or when the user accesses this same directory later, an index is available for use. Refresh the index based on diratime or atime.

4

Very useful post. I was able to find the following:

  • twonky - the twonky web interface. I have disabled this one on mine

  • lltd – it’s a protocol used so that Linux machine can appear in Windows network map

- netatalk – used for better communication with Apple devices

- nfs-common – required for NFS (network filesystem) - do not disable

  • ntpdate - set date and time via NTP (network time protocol)

- openvpn – OpenVPN service, not sure why it’s used

- samba – required for file sharing

I know it’s brief, but I hope it helps someone.

1 Like
5

Thanks marin_todorov, but documenting as “not sure why it’s used” is not really documenting :stuck_out_tongue:

This is what I think openvpn is used for…
OpenVPN is the service needed to do a reverse VPN back to the WD servers if your firewall is blocking the ports. Thus your Cloud will tunnel back to WD and thus you are able to use the Cloud App to access your cloud.

Then again… not sure why it’s used is applicable :stuck_out_tongue:

6

Thanks for replying.

Do you happen to know which daemon is used for mounting the DataVolume shares? I have a problem of my own I am trying to fix and this will really solve my issues :smile:

Regards,
Marin Todorov

7

try mountDataVolume.sh in /etc/init.d but I think you know that already from your other post.

8

Yes, this works, but for some reason it can’t be setup to start automatically. I’ve tried with chkconfig, but to no avail.

9

perhaps check if the wdAutoMount service is running

/etc/init.d/wdAutoMount status

but where ever the system is suppose to mount the data volume, I am thinking that it crashes or a script is stopped before the mounting occurs. so if it stops in chkconfig you might want to edit to comment out all the steps before the mount.