tech notes

Looks like there’s a hidden command you can use to fix queue problems similar to these:

Critical: Queue: Your queue has been corrupted; UNABLE TO REPAIR: unable to
mount queue: ‘(\’qstore/gcq.py get_time_sorted_gens|919\’, “ \'exceptions.OSError\'>“, “[Errno 2] No such file or directory:
\’/var/db/godspeed/gen/gen063.chk\’”, \’[qstore/gcq.py mount|1387]
[qstore/gcq.py load|996] [qstore/gcq.py get_time_sorted_gens|919]\’)’

Critical: Error while sending alert: Unable to send System/Critical alert to xxx@xxx.com with subject “Critical ironport: Queue: Your queue has been corrupted; UNABLE TO REPAIR: unab…”.

What it means is basically that the workqueue is corrupted and the ironport is unable to accept/deliver emails. Rebooting doesn’t help (doesn’t really change anything). There’s however a way of recovering your ironport from this problem. The hidden command is:

It deletes the broken queue, creates a new one, removes all messages in the system quarantines and reboots the ironport. After this clean up operation your ironport should be as new.

What’s interesting is that by looking at various error messages thrown by Ironports from time to time (especially when something breaks more seriously – doesn’t happen too often Ironports are quite solid) you can actually see what’s running under the hood. Other than it running on something derived from FreeBSD (can’t be that far off it as they actually contribute some code back to the OS) it looks like it’s mostly run by python scripts. That’s interesting from the performance perspective as even the queue management seems to be written in python. Also the database used internally seems to be some version of PostgreSQL. A very nice choice of software…

Haven’t seen anything yet that would suggest what MTA (if it’s not something created by Ironport) is used there. Sure the fact it can write qmail compatible log files doesn’t mean anything )

nothing new or special but certainly worth joting down What’s done in MySQL with auto_increment statement in PosgteSQL is a bit more complicated. It requires creating a sequence first:

CREATE SEQUENCE exp_seq;

and then using it in table definition:

CREATE TABLE exp (id INT NOT NULL PRIMARY KEY DEFAULT nextval(‘exp_seq’), other varchar(30), created_at date);

Sequences are actually more powerfull than MySQL’s auto_increment as they have some interesting options. One of them is INCREMENT BY which can be very useful with some multiple master replication or multiple servers scenarios.

Operations allowed on sequences are: nextval, currval and setval.