Thought this little lot may be of use to someone, except this message has a better subject title to it. Better provide references to the information than repeat it all in here.
http://community.wdc.com/t5/My-Book-Live/REST-API-LOG-seems-to-be-growing-rapidly/td-p/321521
Thought it would also be useful to quote some advise I’ve given to someone onto this thread.
To find out how to stop daemon.log filling up ramlog, exceeding it’s 20M limit and falling back to writing logs directly to the Linux system partition until a fix is available you need to call Western Digital and ask them for advise.
This seems to be a Apple MAC related problem. I use only Microsoft Windows OSes on my network and as such I don’t need the netatalk protocol and services so I’ve stopped them on my MyBook Live and, unfortunatly, I am not MAC expert.
Maybe there is something service on your MAC that you can stop that has got something to do with CNID (By the way, what is CNID and what does it do?) which should cure the MyBook Live logging these repeated errors within daemon.log.
I’ve been made aware that Western Digital is working towards the MBL’s Linux OS managing it’s log files a lot better than it is now and the CNID issue has been known for quite a while. I suspect that Western Digital is not rushing to get the next firmware released and may be trying to get things as robust as possible.
As you’ll see, between a few others and myself there has been a lot going on within the discussion forum that’ll have the development team at W.D. scratching their heads for a while.
If youy can get your MAC to use the SMB protocol to access files on the MyBook Live and not use AppleTalk and/or AFP then you can turn off the AppleTalk service on your MyBook Live until a re-boot or power-cycle event to which each time you will need to disable the netatalk service.
To turn off AppleTalk services on the MyBook Live . . .
/etc/init.d/netatalk stop
To start the service on the MyBook Live . . .
/etc/init.d/netatalk start
. . . or reboot the MyBook Live.
It’s the only workaround I know at this present moment. You should get file services. Other services like TimeMachine may stop working because AppleTalk services on the MyBook Live would be turned off.
Hope that helps.
henlihai wrote:
hi Myron,
I have removed both daemon.logs and reboot.
[Solved] No more blinking green
[Solved] Able to access UI normally
/var/www/Admin/webapp/config$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/md1 1.9G 979M 846M 54% /
tmpfs 50M 0 50M 0% /lib/init/rw
udev 10M 6.7M 3.4M 67% /dev
tmpfs 50M 0 50M 0% /dev/shm
tmpfs 50M 2.9M 48M 6% /tmp
ramlog-tmpfs 20M 20M 0 100% /var/log
/dev/sda4 2.8T 164G 2.6T 6% /DataVolume
Yet, I realised that my ramlog-tmpfs under “df -h” is full (100% used of the 20MB), as another new sets of daemon.logs are created (just smaller in size).
Am I suppose to micro-manage the daemon.logs until a fix comes in?
I noticed under /dev/md1 used to be 100% used too. After removing the 2 old daemon.logs. Now it is 54%.
how can I get the ramlog-tmpfs % down to normal levels?
Henry
Myron,
Thank you for your contribution and prompt replies.
I thought I should thank you officially for your contributions here.
I will update in this post when I call WD tomorrow so that others can benefit too.
Thanks once again.
Henry
Hi Myron and Henlihai
First, thank you for your contribution.
I can connect to the MBL via smb (Finder/connect to server/smb://MBL_IP_ADRESS
But, after, i really don’t know what to do…
I only see the Public folder in the Finder.
With the terminal, I don’t know how to acess to the MBL via SMB.
Could you please explain me/us how to erase the deamon.log file and stop Netatalk ?
Your help will be really very veru appreciated ! 
Before I continue, can you login to the Dashboard UI and get at the MyBook Live’s main menu using your web browser.
Hi,
Until last week, I can’t connect to the Dashboard with my browser, even with the IP adress or http://mybooklive.local/UI/
I no longer have access to Quickview (I have a Mac with OS X Lion).
Thank’s for your help
Right… I’ve read a few artcles on here of which some solutions make sense and others don’t. Someone’s managed to get access to their Dashboard UI by either turning UPnP on his router on or off. Don’t know where th discussion thread is for that. Someone else, I think, just pulled the power from the MBL and when it booted up the Dashboard UI had returned and he then managed to enable SSH for back-end access in case it went gaga again.
In your case the discussion thread that may have the comprehensive description and solution/workaround is:
The only issue here is that it all relies on SSH being enabled. If SSH is not enabled and you can’t enable it then you’re stuck. Unless you’re happy to vois your warranty, crack open the case of the MBL, connect it as a external USB drive on your MAC and make, the fixes that way (remembering to edit a config file to enable SSH) and reasembling your MBL then your only real option is to send the MBL back to W.D. and get them to send you back a re-certified MBL.
In a not shell there is some sort of issue between MACs and the netatalk on the MBL that causes the log file daemon.log to explode in size, exceeding the ramlog cache, then fills up the system pertition leaving no room for the MBL’s Linux OS to write or change anything. The MBL’s web server does not like that one bit. W.D. are working towards a fix and also a fix to a few other things.
Right now the only workaround seems to be to disable netatalk on the MBL and access it from the MAC using only the SMB protocol.
Hi,
Here is what I have done :
Everything runs fine, the update was made and the drive has made his reboot.
→ After that : Still no access to the Dashboard (blank screen)
→ After that : Still no access to the Dashboard (blank screen) after reboot
I have aded the missing lines show in your post : MANUAL_EXTERNAL_HTTP_PORT=
MANUAL_EXTERNAL_HTTPS_PORT=
TOTAL_SETTINGS=17
-> After that : Still no access to the Dashboard (blank screen) after reboot
The good news is that I can acess to the drive via ssh.
The bad news is that… nothing has changed.
As I use a Mac and Time Machine, I have not stop the netatalk process yet.
Check /etc/hosts to see if that is intact.
Myron,
What is /etc/hosts suppose to look like? Mine contains this:
MyBookLive02:~# pg /etc/hosts
???
which doesn’t look right.
Mine is very small and contains only this :
admin:
Something is getting corrupted because the hosts file is churned up and why the hosts file is getting churned up is at present a mystery. It’s causing other things to go wrong. (W.D. are aware of the churned up hosts file issue.)
Assuming that the name of your MBL is MyBookLive then alter the hosts file so it has one line that reads . . .
127.0.0.1 localhost.localdomain localhost mybooklive
Obviously substitude mybooklive with the name you have given to your NAS. If you changed its network name.
Ensure that the system partition is not full-up. The log files daemon.log and daemon.log.1 are the culprits for that. Get rid of them or move them to \DataVolume if you think they’ll be needed for diagnostice purposes.
Ensure that the following two files are correctly formed and they should be identical.
/var/www/Admin/webapp/config/dynamicconfig.ini
/var/www/Admin/webapp/config/dynamicconfig.ini_safe
Details of what the above files are supposed to be is reference at the first post of this discussion thread. Trying not to duplicate information. 
Reboot your MyBook Live and see if your Dashboard UI comes back as well as other functionality that gone ape.
Will be interesting to know if this sorts out the problem.
I have copy/paste your text line :
127.0.0.1 localhost.localdomain localhost mybooklive
in the hosts file (My MBL name is still mybooklive).
dynamicconfig.ini and dynamicconfig.ini_safe are the same and they look like that :
[config]
SUBDOMAIN=“”
DEVICEID=“88437”
DEVICEAUTH=“a6c5dd2cf4c792caa9be27199f018629”
EXTERNAL_IP=“”
EXTERNAL_PORT=“”
EXTERNAL_SSL_PORT=“443”
INTERNAL_IP=“10.0.1.2”
INTERNAL_PORT=“80”
DEVICE_SSL_PORT=“443”
REMOTEACCESS=“TRUE”
COMMUNICATION_STATUS=“relayed”
DEFAULT_PORTS_ONLY=“FALSE”
MANUAL_PORT_FORWARD=“FALSE”
MANUAL_EXTERNAL_ROUTER_IP=“MANUAL_EXTERNAL_HTTP_PORT”
I had erase daemon.log and daemon.log.1 this morning.
Here is what I can find now in daemon.log (daemon.log.1 not existing anymore)
I have put the file in the repertory DataVolume, and then I have reboot the drive (with putty, cmd Reboot).
Still no access to the Dashboard after the reboot.
After the rebbot, the brand new file daemon.log looks like that :
Jan 6 16:07:16 localhost dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 5
Jan 6 16:07:16 localhost dhclient: DHCPOFFER from 10.0.1.1
Jan 6 16:07:16 localhost dhclient: DHCPREQUEST on eth0 to 255.255.255.255 port 67
Jan 6 16:07:16 localhost dhclient: DHCPACK from 10.0.1.1
Jan 6 16:07:17 localhost logger: ip changed - reload mDNSResponder
Jan 6 16:07:18 localhost logger: ip changed - restart upnp
Jan 6 16:07:23 localhost dhclient: bound to 10.0.1.2 -- renewal in 42747 seconds.
Jan 6 16:08:47 localhost ifplugd(eth0)[2374]: ifplugd 0.28 initializing.
Jan 6 16:08:47 localhost ifplugd(eth0)[2374]: Using interface eth0/00:90:A9:B5:B5:99 with driver <ibm_emac> (version: 3.54)
Jan 6 16:08:47 localhost ifplugd(eth0)[2374]: Using detection mode: SIOCETHTOOL
Jan 6 16:08:47 localhost ifplugd(eth0)[2374]: Initialization complete, link beat detected.
Jan 6 16:08:47 localhost ifplugd(eth0)[2374]: Could not open /dev/tty, cannot beep.
Jan 6 16:08:47 localhost ifplugd(eth0)[2374]: Executing '/etc/ifplugd/ifplugd.action eth0 up'.
Jan 6 16:08:47 localhost ifplugd(eth0)[2374]: client: /sbin/ifup: interface eth0 already configured
Jan 6 16:08:47 localhost ifplugd(eth0)[2374]: Program executed successfully.
Jan 6 16:08:47 localhost rpc.statd[2409]: Version 1.2.1 Starting
Jan 6 16:08:47 localhost sm-notify[2410]: Failed to open /var/lib/nfs/sm.bak: No such file or directory
Jan 6 16:08:47 localhost rpc.statd[2409]: statd running as root. chown /var/lib/nfs/sm to choose different user
Jan 6 16:09:42 localhost ntpdate[2325]: step time server 207.46.250.85 offset 53.777381 sec
Jan 6 16:09:43 localhost cnid_metad[2497]: Set syslog logging to level: LOG_NOTE
Jan 6 16:09:43 localhost [2534]: Set syslog logging to level: LOG_NOTE
Jan 6 16:09:43 localhost afpd[2535]: AFP/TCP started, advertising 10.0.1.2:12548 (2-2-0-p3)
Jan 6 16:09:59 localhost afpd[2535]: AFP/TCP started, advertising 10.0.1.2:548 (2-2-0-p3)
Jan 6 16:10:07 localhost afpd[2535]: volume "Public" does not support Extended Attributes, using ea:ad instead
Jan 6 16:10:07 localhost avahi-daemon[2860]: Found user 'avahi' (UID 107) and group 'avahi' (GID 110).
Jan 6 16:10:07 localhost avahi-daemon[2860]: Successfully dropped root privileges.
Jan 6 16:10:07 localhost avahi-daemon[2860]: avahi-daemon 0.6.25 starting up.
Jan 6 16:10:07 localhost avahi-daemon[2860]: Successfully called chroot().
Jan 6 16:10:07 localhost avahi-daemon[2860]: Successfully dropped remaining capabilities.
Jan 6 16:10:07 localhost avahi-daemon[2860]: No service file found in /etc/avahi/services.
Jan 6 16:10:07 localhost avahi-daemon[2860]: ***WARNING: Detected another IPv4 mDNS stack running on this host. This makes mDNS unreliable and is thus not recommended.***
Jan 6 16:10:07 localhost avahi-daemon[2860]: Joining mDNS multicast group on interface eth0.IPv6 with address fe80::290:a9ff:feb5:b599.
Jan 6 16:10:07 localhost avahi-daemon[2860]: New relevant interface eth0.IPv6 for mDNS.
Jan 6 16:10:07 localhost avahi-daemon[2860]: Joining mDNS multicast group on interface eth0.IPv4 with address 10.0.1.2.
Jan 6 16:10:07 localhost avahi-daemon[2860]: New relevant interface eth0.IPv4 for mDNS.
Jan 6 16:10:07 localhost avahi-daemon[2860]: Network interface enumeration completed.
Jan 6 16:10:07 localhost avahi-daemon[2860]: Server startup complete. Host name is MyBookLive.local. Local service cookie is 1114156543.
Myron,
Things have settled down considerably for me after fixing all the damage. My ramlog doesn’t seem to be going crazy anymore:
Filesystem Size Used Avail Use% Mounted on
/dev/md1 1.9G 982M 844M 54% /
tmpfs 50M 0 50M 0% /lib/init/rw
udev 10M 6.7M 3.4M 67% /dev
tmpfs 50M 0 50M 0% /dev/shm
tmpfs 50M 3.2M 47M 7% /tmp
ramlog-tmpfs 20M 4.7M 16M 24% /var/log
/dev/sda4 1.9T 51G 1.8T 3% /DataVolume
My Dashboard UI, which became bricked again today, is no longer bricked. Daemon.log seems to be behaving itself:
MyBookLive02:~# ll /var/log/daem*
-rw-r–r-- 1 root adm 8751 Jan 6 18:23 /var/log/daemon.log
I successfully mounted my MBL to my MAC Air then successfully wrote and deleted a folder to it.
So things seem to be settling down… for now… time… will… tell… however…
I would still like to hear from WD on what is causing this and also hear that they have a perminent fix as I am reluctant to put anything major on the drive until these isses are sorted.
WDTony any news???
By the way all you users that have bricked MBLs go the “exchange to a re-certified MBL” route and ensure WD pays for the return postage of your BRICKED unit!!! It cost me CD$52 to courier my BRICKED MBL back to WD via a RMA. So the total cost of this little adventure is over CD$200 and counting!!! That does not take into acount all of the hours I have spent backing up data to and from drives and trouble shooting this thing. Makes me think I should have spent the money and gone with another manufacturer’s NAS.
The next time I get one of those surveys from WD I am going to be very critical.
One thing Myron: manually pruning:
Filesystem Size Used Avail Use% Mounted on
/dev/md1 1.9G 982M 844M 54% /
tmpfs 50M 0 50M 0% /lib/init/rw
udev 10M 6.7M 3.4M 67% /dev
tmpfs 50M 0 50M 0% /dev/shm
tmpfs 50M 3.3M 47M 7% /tmp
ramlog-tmpfs 20M 7.0M 13M 35% /var/log
/dev/sda4 1.9T 51G 1.8T 3% /DataVolume
Pre-prune:
MyBookLive02:~# ll /var/log/daem*
-rw-r–r-- 1 root adm 8751 Jan 6 18:23 /var/log/daemon.log
Post prune with vi:
MyBookLive02:/var/log# ll daemon.log
-rw-r–r-- 1 root adm 2456 Jan 6 19:47 daemon.log
doesn’t seem to affect a positive change in ramlog:
Filesystem Size Used Avail Use% Mounted on
/dev/md1 1.9G 982M 844M 54% /
tmpfs 50M 0 50M 0% /lib/init/rw
udev 10M 6.7M 3.4M 67% /dev
tmpfs 50M 0 50M 0% /dev/shm
tmpfs 50M 3.3M 47M 7% /tmp
ramlog-tmpfs 20M 7.0M 13M 35% /var/log
/dev/sda4 1.9T 51G 1.8T 3% /DataVolume
Is there something else I should be pruning or running?
So, I shut the MBL down last night because I could see the ramlog building to critical (i.e. near 65% full) and with no way of effectively pruning it and no users needing it and the thing never going into sleep mode… well you get the idea.
When I turned it back on this morning here is what I found:
The daemon.log looks like this at start-up:
So clearly something starts to go off the rails soon after start-up.
Any ideas?
ThierryB, your dymanicconfig files are incorrect.
Change MANUAL_EXTERNAL_ROUTER_IP="MANUAL_EXTERNAL_HTTP_PO** RT" to MANUAL_EXTERNAL_ROUTER_IP=“”**
Also add the lines . . .
MANUAL_EXTERNAL_HTTP_PORT="80"
MANUAL_EXTERNAL_HTTPS_PORT="443"
TOTAL_SETTINGS="17"
here is what log.hdd looks like:
Can I prune something in here to get ramlog back down to non-critical?
What’s causing this:
? I can’t use this drive until this is fixed!
Hi Myron,
I have corrected the 2 files and now I have access to the Dashboard !
Thank’s a lot ! :-))
| Forums | News and Announcements | Register | Help | Forum Guidelines |
Copyright © 2021 Western Digital Technologies, Inc. All rights
reserved.
|
Trademarks
|
Privacy
|
Community Terms of Service
|
Site Terms of Use
|
Copyright
|
Contact WD
|