We’re trying to get Request Tracker (1.0.7) set up, with qmail (1.03) being
used for mail service. We’re using procmail as the local delivery agent.
We’re using Maildir/ style mailboxes, and procmail has been compiled with
support for them. We changed the group for Request Tracker to wheel in
the makefile, and changed the sendmail options also.
We’re going to go into some detail about what’s happening. We’ve left out
out some details about how qmail works, but from searching the rt-users
archives, it appears there are some members of the list who are experienced
qmail admins, and hopefully they’ll be able to help us.
The problem we’re having is this:
Mail is received for our Request Tracker address, email@example.com, and
is passed to the rt-mailgate script. The mail message is copied into the
ticket, and a response is sent to the requestor. Qmail however, does not
finish delivery, and the message remains in the queue. We’ve seen users
in the archives mentioning they’ve used Request Tracker with qmail
ls -la /var/qmail/alias/.qmail-tickets
-rw-r–r-- 1 root qmail 52 May 6 00:04 /var/qmail/alias/.qmail-tickets
In /var/qmail/alias/.qmail-tickets we have
|preline /var/rt/bin/rt-mailgate tickets correspond
When an email comes in addressed to firstname.lastname@example.org, we see these
alias 78012 0.0 0.1 620 244 ?? S 4:39AM 0:00.01 /bin/sh -c preline /var/rt/bin/rt-mailgate tickets correspond
alias 78013 0.0 0.1 872 360 ?? S 4:39AM 0:00.01 preline /var/rt/bin/rt-mailgate tickets correspond
rt 78014 48.2 1.3 3940 3324 ?? D 4:39AM 0:01.13 /usr/bin/perl -T /var/rt/bin/rtmux.pl rt-mailgate tickets correspond
rt 78019 0.0 0.0 0 0 ?? Z 4:39AM 0:00.00 (qmail-inject)
All of these processes will now hang around for a while until we kill them.
(We didn’t let them stay longer than a day.) We noticed that the last rt
process (78019) is a zombie.
We also notice the first alias process is (to us) doing something funky.
However, we’re not sure how each argument on that line is being used by
Perhaps there is a problem with procmail and the mailgate script.
In the qmail logfile, we see:
2001-05-06 04:39:38.753166500 starting delivery 2: msg 214326 to local tickets@k
2001-05-06 04:39:38.758490500 status: local 1/10 remote 0/20
2001-05-06 04:39:41.861612500 new msg 214327
2001-05-06 04:39:41.867125500 info msg 214327: bytes 1775 from <anonymous@klatsc
h.org> qp 78020 uid 89
2001-05-06 04:39:41.956685500 starting delivery 3: msg 214327 to local cjack@kla
2001-05-06 04:39:41.960322500 status: local 2/10 remote 0/20
2001-05-06 04:39:42.203451500 delivery 3: success: did_0+0+1/
2001-05-06 04:39:42.206103500 status: local 1/10 remote 0/20
2001-05-06 04:39:42.206122500 end msg 214327
2001-05-06 04:40:14.215884500 starting delivery 4:
<snipped because delivery 4 and everything after is unrelated. just wanted
to show that qmail continues to deliver any other mail in the queue.>
We noticed that there is no delivery 2: success message, nor is there
ever for any other email to email@example.com.
We also notice that the queue status (in this case 1/10) will stay that
way until we manually remove the message from the queue. It will increment
if we send more email to tickets.
If we kill all the alias processes first, and then kill the rt process (78014
above) that is doing “perl -T /var/rt/bin/rtmux.pl rt-mailgate tickets
correspond”, we see this in the qmail logs:
2001-05-06 05:03:26.769179500 delivery 2: deferral: qmail-local_crashed./
If we kill that process (78014 above) first, without killing the alias
processes, we see this in the logs, and the alias processes disappear:
2001-05-06 05:20:59.743902500 delivery 20: deferral: preline:_fatal:_child_crash
We went searching through the rt-users mailing list, and found a few posts
mentioning qmail. Those posts agree with what is in our
We tried setting up a tickets user, with a home directory of /home/tickets,
and a .qmail file of |preline /var/rt/bin/rt-mailgate tickets correspond
The same thing occurred.
We’re not sure what’s causing the problem here. We thought that the
rt-mailgate script forked, which qmail-send does not like. Especially since
killing the alias processes generates a log message of