I just discovered a highly unusual issue that really made me laugh…
We have an application that generates event logfiles which contain, among other items, a processing time in ms. These logfiles are parsed by a different application.
On 2009-01-01 at 00:59:59 local time (UTC+1) this application generated an exception because it couldn’t properly parse the logfile. There was a negative processing time which should never occur. WTF?!
Considering the strange date and time and then thinking about it some fractions of a second (;-)) I immediately found the reason for this strange issue:
Exactly at that time a so-called “leap second” was inserted, so that 00:59:59 occurred “twice.” And since the second occurence was just between the first and second measure point, we had a negative duration of 912 ms (instead of 88 ms.)
Now, is that a strange problem??? Can you beat that?!
I’m using a small Perl script to send SMS for Nagios notifications. Up to now I didn’t have any flood control (i. e. logic that limits the rate of messages to be sent) built into the script, which made me feel bad (especially since I had already been SMS-bombed a while ago when the link to the servers to be monitored broke down).
My search for some Perl sample code that implements flood control led me to an article on Perl.com and the CPAN Perl package Algorithm::FloodControl, which does exactly what I need and which is easy to use at the same time. I very much recommend this package.
I need to monitor whether the number of active connections against a MySQL server is within a “reasonable” range.
For all my monitoring needs, I use Nagios. Of course, Nagios offers a MySQL monitoring plugin, however, it does not suit my needs. It only allows you to perform queries on tables, which doesn’t allow me to retrieve the number of current connections to the database server (or does it?!).
I just had a nightmarish experience when I upgraded Debian’s unstable WordPress package to version 2.1. When I invoked my site for the first time, WordPress prompted me to upgrade its database — which I did, of course, or rather “I tried to do.”
After I started the upgrade, I saw a dozen or so error messages rushing over my screen. When I analyzed them, I quickly recognized that the database user didn’t have sufficient permissions to perform certain table alterations. I thought, “Hey, no prob, correct the permission problems, and re-run everything.”
But “Not so!” WordPress was able to write the new WP database version no. into the database in the last step of the upgrade procedure, so the upgrade refused to run again because it thought the database was already current.