I think I’ve bought 10 different Dell laptops in the last 8 years or so. They’ve all done their jobs admirably apart from one memorable XPS laptop which can only be charitably described as a piece of poo. That laptop gave me nothing but troubles from day one and despite Dell’s best efforts (and 4 or 5 on-site visits from a tech) could never be made to work correctly. To Dell’s credit they gave me an exchange computer to replace that computer and the replacement (a Vostro 14″ machine) has been flawless.
Anyway, my partner has been using a 15.5″ consumer grade Inspiron with Windows Vista for the last 4 years and it was starting to have some problems. I hate fiddling with computers to fix up glitches, especially 4 year old computers that are well past their use-by date. So rather than fix that PC off to the Dell Australia Outlet Store I went. I’ve had some luck picking up cheap machines and monitors from there in the past so I thought I’d try my luck again. The only criteria for the new machine were that it be a laptop, that it have Windows 7×64, and it have 8GB of RAM. There we a couple of likely prospects, one of which was an Inspiron and the other was a Vostro 3560. Ten minutes on the phone to Dell told me that the Inspiron wasn’t available any longer but the Vostro was and the purchase was made. 5 days later the new machine landed on our front doorstep.
The Dell Vostro 3560 seems like a nicely built machine. It’s certainly much nicer to handle and look at than the old Inspiron clunker it replaced. 4 hours of fluffing about with it last night as I moved the data from the old machine to the new one showed no problems at all with performance being snappy. Hardware wise the USB ports are a trifle stiff to get plugs into but the monitor is excellent with a 1920×1080 resolution. Even with a titchy 15.5″ monitor everything was quite readable at this resolution.
Of course this is no long term test but after 12 hours in our life the Dell Vostro 3560 laptop has done what it’s supposed to do perfectly. Recommended.
This entry is really here to remind me what went wrong with Munin so the next time it happens I am likely to remember. I use Munin on my web servers to monitor them. I run Munin nodes on the web-servers and the Munin master is another computer that just serves up the Munin web pages and runs some rsync commands via cron jobs. This system has been working faultlessly for 2 years and then on September 26 2012 it stopped updating the graphs. Yesterday I finally got around to figuring out why it didn’t work any longer.
First thing I did was take a look at the munin logs on the clients, these are in the /var/log/munin directory. These logs were showing a last modified date of September 26, the same date the munin graphs stopped updating. I opened up the last log in nano and there was exactly nothing of help in there. So I tried re-starting the munin node process with:
I sat there watching the log files for 5 minutes hoping they’d update. Sadly they didn’t. So I started up a new PuTTY session with the machine running the munin master took a look at the munin logs in /var/log/munin/. They all had the September 26 modified date too. I had a quick look through the logs and couldn’t see anything in there either. Next step was to force a manual update of the munin master and see what happened there. I did this by changing to the munin user with:
su - munin --shell=/bin/bash
And then running the munin-update (which gets all the data from the munin-clients)
When I ran this command the update, which should be hundreds of steps was just four steps with the last one complaining about there being no free disk space! Eureka!
Next step was to check the disk usage on the server. I sorted this by directory and displayed it in human readable format with:
du -sh * | sort
This indicated that a directory that contained database backups was using up almost all the disk space on the server. A quick removal of older files from this location freed up a lot of space. I forced a munin update again and hey presto everything started working.
All of this would have been easily solved if I actually had munin monitoring the server that acts as my munin master, but of I course I haven’t done that. Stupid me. I’ll put that on the to-do-list, but for now at least the problem is solved and will not re-occur for several months.