Bug 126760 - [PATCH] method to specify persistent queue runners?
[PATCH] method to specify persistent queue runners?
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: sendmail (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Thomas Woerner
: FutureFeature, Reopened
Depends On:
Blocks: 200921
  Show dependency treegraph
Reported: 2004-06-25 19:56 EDT by James Ralston
Modified: 2007-11-30 17:07 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-07-24 11:58:21 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
patch for sendmail init.d script (452 bytes, patch)
2004-06-28 02:54 EDT, James Ralston
no flags Details | Diff

  None (edit)
Description James Ralston 2004-06-25 19:56:28 EDT
For my site, I need to be able to run persistent queue runners instead
of regular queue runners.

A regular queue runner is invoked with the "-q" option:

    /usr/sbin/sendmail -q1h

A persistent queue runner is invoked with the "-qp" option:

    /usr/sbin/sendmail -qp1h

The problem is that the sendmail init.d script (and sysconfig file)
don't permit a way to say "run persistent queue runners instead of
regular queue runners".

For now, I've just edited my sendmail init.d script to do what I want.
 But I'd like to find a cleaner, more general solution.

The current syntax for the sendmail sysconfig file is:


I was thinking of adding support for two more variables, used thusly:


QUEUEFLAG, if specified, overrides QUEUE; SMQUEUEFLAG, if specified,
overrides SMQUEUE.  Rather than just specifying the interval, the
*FLAG variables specify the exact -q flag to pass to sendmail.

Thus, I could do what I want putting this in my sendmail sysconfig file:


If you find this solution acceptable, please indicate as much and I'll
supply a patch to implement it.

Alternatively, if there is some other method you'd prefer to use to
add this functionality, please let me know.
Comment 1 James Ralston 2004-06-28 02:53:25 EDT
Actually, since the option for a persistent queue runner ("-qp") has
the option for a regular queue runner ("-q") as a prefix, perhaps it
would be better to just overload the use of QUEUE and SMQUEUE.  E.g.:


This requires a small patch to the sendmail init.d script, which I'll
attach next.
Comment 2 James Ralston 2004-06-28 02:54:06 EDT
Created attachment 101458 [details]
patch for sendmail init.d script
Comment 3 Suzanne Hillman 2004-08-09 11:40:12 EDT
Internal RFE bug #129473 entered; will be considered for future releases.
Comment 6 Thomas Woerner 2004-10-19 05:35:05 EDT
Closing as "WONTFIX".
Comment 7 James Ralston 2004-10-20 18:09:17 EDT

I mean, the sendmail init.d file isn't even consistent right now:

daemon /usr/sbin/sendmail $([ "x$DAEMON" = xyes ] && echo -bd) \
                $([ -n "$QUEUE" ] && echo -q$QUEUE) $SENDMAIL_OPTARG


daemon --check sm-client /usr/sbin/sendmail -L sm-msp-queue -Ac \
                -q $SMQUEUE $SENDMAIL_OPTARG

(This is still true with sendmail-8.13.1-2.i386.rpm in Nahant.)

Why is my 1-line patch to use "-q$SMQUEUE" instead of "-q $SMQUEUE"
not acceptable?
Comment 8 James Ralston 2005-02-07 13:33:21 EST
Any progress on this?

I know that sendmail currently treats e.g. "-q 1h" as equivalent to "-q1h", but
that behavior isn't documented anywhere that I've been able to find, so I think
it would be best to apply my one-line patch.
Comment 9 Red Hat Bugzilla 2007-02-05 14:20:10 EST
REOPENED status has been deprecated. ASSIGNED with keyword of Reopened is preferred.
Comment 10 Thomas Woerner 2007-07-23 05:44:20 EDT
This has been fixed for RHEL-4+
Comment 11 Thomas Woerner 2007-07-24 11:57:52 EDT
This request was evaluated by Red Hat Engineering for inclusion in a Red
Hat Enterprise Linux maintenance release.

Red Hat does not currently plan to provide this change in a Red Hat Enterprise
Linux update release for currently deployed products.

With the goal of minimizing risk of change for deployed systems, and in
response to customer and partner requirements, Red Hat takes a conservative
approach when evaluating enhancements for inclusion in maintenance updates
for currently deployed products. The primary objectives of update releases
are to enable new hardware platform support and to resolve critical

However, Red Hat will further review this request for potential inclusion
in future major releases of Red Hat Enterprise Linux. 

Note You need to log in before you can comment on or make changes to this bug.