0

I have a Model B Raspberry Pi running the latest version of Raspbian, with all the packages up-to-date. It's fitted with a 32G SD card and its only purpose is to display a dashboard with some metrics. It has a wired connection and a modified rc.local file that starts midori in fullscreen mode, as well as a cron job that runs every five minutes to check that the internet is up, and to refresh the dashboard in case it was down.

The cronjob was a recent addition because our current internet provider is rather flaky, and we experience a higher-than-average downtime, so I added it in an attempt to have a dashboard with as much uptime as possible. But I noticed that after I added it, I kept seeing "Cannot allocate memory" errors whenever I attempted to run commands on the pi. I did some searching and found this answer on askubuntu, so I tried some of the troubleshooting suggestions:

pi@dashboard1 ~ $ free -h
             total       used       free     shared    buffers     cached
Mem:          247M       211M        35M         0B        13M        77M
-/+ buffers/cache:       121M       125M
Swap:          99M         0B        99M

pi@dashboard1 ~ $ ps --sort -rss -eo rss,pid,command | head
  RSS   PID COMMAND
75000  2142 midori --log-file=/var/log/midori/debug.log -e Fullscreen -a https://www.leftronic.com/share/rO7onq/#rO7onq
19176  2128 X :0
 4364  2141 matchbox-window-manager
 3396  4621 -bash
 2944  4616 sshd: pi [priv]  
 2096  1603 dhclient -v -pf /run/dhclient.eth0.pid -lf /var/lib/dhcp/dhclient.eth0.leases eth0
 2092  2205 dhclient -v -pf /run/dhclient.eth0.pid -lf /var/lib/dhcp/dhclient.eth0.leases eth0
 2092  2314 dhclient -v -pf /run/dhclient.eth0.pid -lf /var/lib/dhcp/dhclient.eth0.leases eth0
 2092  2426 dhclient -v -pf /run/dhclient.eth0.pid -lf /var/lib/dhcp/dhclient.eth0.leases eth0

This looks to me like midori is leaking memory, although the number of dhclient processes also seems odd?

Here's the bash script that is run every five minutes on cron:

if [[ -e $lockfile ]] ; then
    pid="$(cat $lockfile)"

    # Check if a wifi check is currently running
    if [[ "$(kill -0 "$pid" &> /dev/null)" -eq 0 ]] ; then
        # Check is running; let it be
        exit 1
    else
        # This lockfile is now old; delete it
        rm $lockfile
    fi
fi

# Set the lockfile with the pid of this process
echo $$ >| $lockfile

sudo ifup --force $interface
sleep 5
/home/pi/dashboard1/reload.sh  # script to reload dashboard

rm $lockfile

And this is my /etc/rc.local (only the line before last has been added):

#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.

# Print the IP address
_IP=$(hostname -I) || true
if [ "$_IP" ]; then
  printf "My IP address is %s\n" "$_IP"
fi

sudo xinit /home/pi/dashboard1/start_midori.sh &
exit 0

And here is the start_midori.sh script referenced above:

#!/bin/bash

while true ; do
  xset -dpms        # disable DPMS (Energy Star) features
  xset s off        # disable screensaver
  xset s noblank    # don't blank the video device

  unclutter &       # hide the mouse pointer
  matchbox-window-manager &

  WEBKIT_IGNORE_SSL_ERRORS=1 midori --log-file=/var/log/midori/debug.log -e Fullscreen -a 'http://www.mydashboardurl.com'
done

Any advice would be highly appreciated. Currently I have the Pi's rebooting every morning on a cronjob, but that's only a bandaid solution.

2

According to your free output you have 125 MB available, more than half your total. If this is a B with 512 MB, you have allocated way to much to the GPU. If you are using HD video or 3D graphics, 128 MB should be plenty. If you are doing normal web page stuff in Midora (you mention a dashboard), 8 or 16 MB is fine.

You don't describe or provide an example of the "Cannot allocate memory" errors you are getting which makes this hard to diagnose, since obviously the system is not out of memory.

This looks to me like midori is leaking memory

It does not look that way at all. "Leaking memory" means allocating it without returning it back to the system pool properly. Midori is currently using 75 MB, which is pretty decent. Currently on my laptop firefox is using 340 MB.

the number of dhclient processes also seems odd?

I'll agree with that; I don't see why there needs to be more than one. In fact, I don't know how it could be done, since dhclient will refuse to start if running and the default port is taken by a previous instance. You should compare this to the output from lsof -i UDP:68.

  • Thanks for your reply - you're absolutely right, it doesn't seem like it has anything to do with midori, I just assumed as from a cursory look it seemed like it was using more and more memory every time I checked. However, that said, I tried running lsof -i UDP:68, but that didn't give me anything. I've also set the GPU memory to 16 and rebooted. It's very odd, but I've been monitoring the dhclient processes and the number has been steadily growing. It seems like the ifup command in the script is starting a new dhclient process every time it is being run. Currently investigating. – 3cheesewheel Jan 22 '15 at 19:58
  • 2
    Yes - seems like the --force option for ifup is launching a dhclient process every time that command is run (sudo ifup --force eth0). I've removed that option and it looks like the spawning of new dhclient processes has stopped. Thanks again for your help! – 3cheesewheel Jan 22 '15 at 20:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.