Raspberry Pi sensors – Munin graphing plugin

I love Munin!  I’ve finally got one of the Raspberry Pi’s to be reasonably stable, so I’ve set up a munin-node on it.  The standard Linux sensord stuff doesn’t run on the arm core, so I had assumed I wouldn’t be able to see any exciting temperature graphs, but I was wrong!

The Raspberry Pi Debian image includes a command called vcgencmd, which allows root to interrogate various settings and measurements.  That includes the temperature, clock frequencies and voltages across various components.

So I’ve knocked up a quick plugin for Munin which gathers that stuff and graphs it.  You can get it over at GitHub here.  The current code looks like this (but the GitHub copy will be most up-to-date),

[sourcecode language=”bash”]
#!/bin/bash
# -*- sh -*-

: << =cut

=head1 NAME

pisense_ – Wildcard-plugin to monitor Raspberry Pi sensors (temp, volts, clock speed)

=head1 CONFIGURATION

This plugin needs to be run as root for vcgencmd to work.

[pisense_*]
user root

=head2 ENVIRONMENT VARIABLES

This plugin does not use environment variables.

=head2 WILDCARD PLUGIN

This is a wildcard plugin. To specify if you want temperature,
clock speed or volts, link this file to _volt, _temp
or _clock.

For example,

ln -s /usr/share/munin/plugins/pisense_ \
/etc/munin/plugins/pisense_clock

will monitor the clock speeds of your pi.

=head1 BUGS

None known.

=head1 NOTES

This plugin is shamelessley based on the ip_ plugin (structure).

=head1 MAGIC MARKERS

#%# family=auto
#%# capabilities=autoconf suggest

=head1 AUTHOR

Tony (tony@darkstorm.co.uk).

=head1 LICENSE

It’s yours, do with it what you like.

=cut

. $MUNIN_LIBDIR/plugins/plugin.sh

sensor=${0##*/pisense_}

if [[ "$1" == "autoconf" ]]; then
if ! /opt/vc/bin/vcgencmd firmware >/dev/null 2>/dev/null; then
echo "no (could not run /opt/vc/bin/vcgencmd as user $(whoami))"
exit 0
else
echo yes
exit 0
fi
fi

# this is flawed, vcgencmd always returns with RC 0. Needs expanding.
if [[ "$1" == "suggest" ]]; then
if /opt/vc/bin/vcgencmd measure_temp >/dev/null 2>/dev/null; then
echo temp
fi
if /opt/vc/bin/vcgencmd measure_volts >/dev/null 2>/dev/null; then
echo volt
fi
if /opt/vc/bin/vcgencmd measure_clock core >/dev/null 2>/dev/null; then
echo clock
fi
exit 0
fi

if [[ "$1" == "config" ]]; then

if [[ "$sensor" == "temp" ]]
then
echo "graph_title Raspberry Pi core temp"
echo "graph_args –base 1000"
echo "graph_vlabel dgrees Celsius"
echo "graph_category sensors"
echo "temp.label Core Temperature"
echo "temp.min 0"
fi
if [[ "$sensor" == "clock" ]]
then
echo "graph_title Raspberry Pi clock frequencies"
echo "graph_args –base 1000"
echo "graph_vlabel herz"
echo "graph_category sensors"
for clock in arm core h264 isp v3d uart pwm emmc pixel vec hdmi dpi
do
echo "clock$clock.label $clock clock Frequency"
echo "clock$clock.min 0"
echo "clock$clock.type GAUGE"
done
fi
if [[ "$sensor" == "volt" ]]
then
echo "graph_title Raspberry Pi voltages"
echo "graph_args –base 1000"
echo "graph_vlabel volts"
echo "graph_category sensors"
for volt in core sdram_c sdram_i sdram_p
do
echo "volt$volt.label $volt voltage"
echo "volt$volt.min 0"
echo "volt$volt.type GAUGE"
done
fi

exit 0
fi;

if [[ "$sensor" == "temp" ]]
then
temp=$(/opt/vc/bin/vcgencmd measure_temp | awk -F"=" ‘{print $2}’ | awk -F"’" ‘{print $1}’)
echo "temp.value $temp"
fi
if [[ "$sensor" == "clock" ]]
then
for clock in arm core h264 isp v3d uart pwm emmc pixel vec hdmi dpi
do
clockval=$(/opt/vc/bin/vcgencmd measure_clock $clock | awk -F"=" ‘{print $2}’)
echo "clock$clock.value $clockval"
done
fi
if [[ "$sensor" == "volt" ]]
then
for volt in core sdram_c sdram_i sdram_p
do
voltage=$(/opt/vc/bin/vcgencmd measure_volts $volt | awk -F"=" ‘{print $2}’ | tr -d "V")
echo "volt$volt.value $voltage"
done
fi
[/sourcecode]

I’ll post some sample screenshots in a bit!

Debian squeeze gdm / Xserver won’t start without a monitor

The little Atom based computer I was using as a Linux server in the house died.  Well technically, the fan died, which led to the rest of it dying.  It’s a proprietary case and motherboard,  so the fan isn’t something I can just pick up and replace (looks like a laptop fan, squeezed into the case), and I need something working faster than I could repair it.  I had a spare PC upstairs, which isn’t as quiet or as energy efficient as the Atom, but at least it works!  (This was after several days of Raspberry Pi’s failing and trashing SDHC cards, so I was already pretty pissed off with hardware, Linux and the whole building it yourself thing).

Anyway, as it happens, Debian reminded me how exceedingly trivial it is to build a server, and since I had full backups of the Atom PC it didn’t take long to get everything back up and running.  I was also reminded how slow the Atom chips can be, the P4 I’ve replaced it with is a world apart in terms of speed for whatever reason.

The Atom machine was running Ubuntu, but it used to frustrate me when it was quite the same as Debian, and I wanted to go back to a basic Debian build.  Also, since the P4 is more stock than the Atom I don’t need the bleeding edge drivers you get with Ubuntu.  All of this did leave me with one issue though.

When connected to a monitor, the Debian build works fine.  It works if you boot it with a monitor and then remove the monitor as well, but if you boot it without a monitor, it won’t start the X Server.  It tries about a million times [1] and then gives up.

I use Gnome under Debian, and because this machine is sitting physically in my house, I enable the autologon, and remote desktop control, so if I want, I can VNC in from my main machine.  I don’t usually need to do it, and I’m comfortable doing everything I want on that box from the command line, but every now and then it’s nice to use one or two GUI based apps.  Since Gnome supports this out of the box, I don’t feel the need to install VNC and start changing the config – it worked under Ubuntu, and it works under Debian if the monitor is there, I just needed it to work without the monitor.

I did a lot of reading around, there are plenty of suggestions about using VNC instead, some suggestions of modifying xorg.conf with some default display settings, and some other stuff.  I tried setting up an xorg.conf (new versions of X don’t use one by default, so you have to create one), but that didn’t seem to help.  More reading, and more playing around, and then I finally found the exact solution.

You can read the original page here.

Essentially, you need to add an entry to xorg.conf as I had been, but even then, X will probably refuse to start, because it detects modesetting drivers in the kernel and refuses to load the VESA driver.  Here’s the specific section from the error log if you get this,

(II) VESA: driver for VESA chipsets: vesa
(EE) VESA: Kernel modesetting driver in use, refusing to load
(WW) Falling back to old probe method for vesa
(EE) No devices detected.

So, as you can see from the document linked above, you need to disable the modesetting and then X will happily start.  This is the /etc/X11/xorg.conf config file I used (same as the original document),

Section "Device"
Identifier "VNC Device"
Driver "vesa"
EndSection

Section "Screen"
Identifier "VNC Screen"
Device "VNC Device"
Monitor "VNC Monitor"
SubSection "Display"
Modes "1280x1024"
EndSubSection
EndSection

Section "Monitor"
Identifier "VNC Monitor"
HorizSync 30-70
VertRefresh 50-75
EndSection

I also used both the i915 modeset change (because I had an i915 config file already), and the Nvidia one, since the machine has an Nvidia card in it.  A quick reboot, gdm and the X Server both started fine.  Very happy!

So the key isn’t just the xorg.conf above, which most people have posted about, you probably have to disable modesetting in the relevant graphics driver as well.

[1] okay, about half a million.

Problems with my Pi

I have a couple of Raspberry Pi’s (long story as to why I have two).  I spent a few hours one day a couple of weeks ago setting one of them up – pretty impressive, but I felt the overall performance was disappointing.  I moved the Pi between rooms in the house, did some more setup and then left it running for a few days.

Everything seemed okay.  Then one morning, it wasn’t responding.  I was running it headless and I could no longer SSH into it.  I had no choice but to power it off because it was no where near a composite or HDMI device.  Once powered off, it wouldn’t boot again at power on.  I carried it back through into the room with a TV, powered it up, and discovered the filesystem was corrupt.

No problem, pull out the SDHC card, whack it into a USB adapter, plug it into another Linux machine and fsck it.  That had a billion errors, I was impressed at quite how badly it had been corrupted.  I didn’t really think much more about it, I had a second SDHC card with raspbian already on it, and I didn’t really do much with the machines for a few weeks.

The day before yesterday, the Linux box I use to backup the other machines developed a fault, so I thought it would be the perfect time to replace it with one of the Pi’s.  Got it all set up on the shelf, hidden away, and ran it for a day.  Terrible disk IO performance, but otherwise okay.  I read around a bit and discovered that the SDHC card performance can be quite bad.  So I put a USB thumb drive in (16GB) with the intention of moving everything except /boot onto that to improve performance.

Except, when I reboot it – it wouldn’t boot.  Sure enough, corrupt filesystem.  I went back to check the original SDHC card and discovered not only was the filesystem corrupt, the card is damaged.  The second card doesn’t appear to be damaged but it would seem any power fluctuation in the Pi, or any power off without a shutdown, can trash the filesystem beyond recovery.

Now I’m concerned the Pi’s aren’t reliable enough to have sitting in the corner running 24×7.  A browse on the web shows I’m not alone either.  Quite disappointing.