After reading the USP and elevator pitch for Ack, someone took the time to review the hype and make his own opinion about ack. It appears to him that although Ack is not a drop-in replacement for Grep, the DWIM factor makes it a very interesting alternative for many situations where interactive use by a human is involved.

So I decided to give it a spin. ‘apt-cache search ack’ matched 15971 packages related to crack, backup, pack, slack and whatever else you can imagine, but an ‘apt-cache search ack | grep -E ^ack’ solved that problem at once.

In Debian, there was already a kanji code converter named “ack” - but since we don’t intend as far as I know to write Kanji anytime soon I tought it was reasonable to alias ack=’ack-grep’ so that our shell takes advantage of the short name.

After toying with it a little, it appears that Ack is indeed a handy tool which I’ll be definitely using in the future. There is a performance tradeoff when operating with the C locale, but since we strive to be an all UTF-8 shop I don’t care much about that. And anyway, in most interactive situations, brain usage and fingers motricity are far more precious ressources than run time or CPU time…

Looking at server logs in search of clues about a recent filesystem corruption incident, I stumbled upon the following messages :

Aug  5 01:06:01 kivu mdadm: RebuildStarted event detected on md device/dev/md0
Aug  5 01:43:01 kivu mdadm: Rebuild20 event detected on md device /dev/md0
Aug  5 02:15:01 kivu mdadm: Rebuild40 event detected on md device /dev/md0
Aug  5 02:59:02 kivu mdadm: Rebuild60 event detected on md device /dev/md0
Aug  5 04:33:02 kivu mdadm: Rebuild80 event detected on md device /dev/md0
Aug  5 05:24:33 kivu mdadm: RebuildFinished event detected on md device/dev/md0

We never asked for a manual rebuild of that RAID array so I started thinking I was on to something interesting. But ever suspicious of easy leads I went checking for some automated actions. Indeed that was a false alarm : I found that a Debian Cron script packaged with mdadm at /etc/cron.d/mdadm contained the following :

# cron.d/mdadm -- schedules periodic redundancy checks of MD devices
# By default, run at 01:06 on every Sunday, but do nothing unless
# the day of the month is less than or equal to 7. Thus, only run on
# the first Sunday of each month. crontab(5) sucks, unfortunately,
# in this regard; therefore this hack (see #380425).

6 1 * * 0 root [ -x /usr/share/mdadm/checkarray ] && [ $(date +%d) -le
7 ] && /usr/share/mdadm/checkarray –cron –all –quiet

So there, Google fodder for the poor souls who like me will at some point wonder why their RAID array spontaneously rebuilds…

Now why does the periodic redundancy check appear like a rebuild ? Maybe a more explicit log would be nice there.

I upgraded the Sympa mailing list manager to 5.2.3-2 using the Debian package from the “Testing” repository. The database part of the upgrade procedure was a bit fussy so instead of solving its problems I simply backed up the tables, dropped them, ran the upgrade procedure and restored them. That workaround worked fine for making the Debian packaging system happy.

But Sympa itself was definitely not happy. On starting Sympa I got the following logs in /var/log/sympa.log :

Apr 25 17:02:39 kivu sympa[657]: Could not create table admin_table in
database sympa : Table ‘admin_table’ already exists
Apr 25 17:02:39 kivu sympa[657]: Could not create table user_table in
database sympa : Table ‘user_table’ already exists
Apr 25 17:02:39 kivu sympa[657]: Could not create table subscriber_table
in database sympa : Table ’subscriber_table’ already exists
Apr 25 17:02:39 kivu sympa[657]: Could not create table netidmap_table
in database sympa : Table ‘netidmap_table’ already exists
Apr 25 17:02:39 kivu sympa[657]: Unable to execute SQL query : You have
an error in your SQL syntax; check the manual that corresponds to your
MySQL server version for the right syntax to use near ‘.`admin_table’ at
line 1
Apr 25 17:02:39 kivu sympa[657]: Database sympa defined in sympa.conf
has not the right structure or is unreachable. If you don’t use any
database, comment db_xxx parameters in sympa.conf
Apr 25 17:02:39 kivu sympa[657]: Exiting.
Apr 25 17:02:39 kivu sympa[657]: Sympa not setup to use DBI

With no database access, Sympa was not operational. Double plus ungood !

The very strange thing is that the database is fine : the right tables with the right fields and the right records are all present. It even worked with the preceding version of Sympa. It looked like Sympa itself was unable to recognize that my database setup was correct, subsequently reported those errors and thereafter refused to run with it at all.

With a little rummaging inside the Sympa-users mailing list I quickly found a report of something looking suspiciously like my problem. It is probably a bug and Olivier Berger proposed a patch that looked to me like a workable solution : according to Olivier, a faulty regex was the cause of Sympa’s failure to recognize it’s own.

After making a backup copy of /usr/lib/sympa/bin/List.pm I promptly applied his patch :

17:04 root@kivu /usr/lib/sympa/bin# diff List.pm.dist List.pm
10750a10751
> $t =~ s/^([^.]+\.)?(.+)$/\2/;

I restarted Sympa and it worked fine ever after. Thank you Olivier !

The only problem is that while Sympa was down, people wondered why the messages did not go through and resent some of their messages. None of those messages were lost - they were just piling up in a queue. So when Sympa restarted many duplicates were sent.

But at least now it’s working. So for now I’m going to use dselect to freeze the Sympa Debian package at its current version so that it is kept back next time I upgrade my system.