Bug 126760 - [PATCH] method to specify persistent queue runners?
Summary: [PATCH] method to specify persistent queue runners?
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: sendmail
Version: 3.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Thomas Woerner
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks: 200921
TreeView+ depends on / blocked
 
Reported: 2004-06-25 23:56 UTC by James Ralston
Modified: 2007-11-30 22:07 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2007-07-24 15:58:21 UTC
Target Upstream Version:
Embargoed:


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

Description James Ralston 2004-06-25 23:56:28 UTC
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:

    DAEMON=yes
    QUEUE=1h
    SMQUEUE=1h

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

    QUEUEFLAG=-q1h
    SMQUEUEFLAG=-q1h

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:

    DAEMON=yes
    QUEUEFLAG=-qp1s
    SMQUEUEFLAG=-qp1s

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 06:53:25 UTC
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.:

    DAEMON=yes
    QUEUEFLAG=p1s
    SMQUEUEFLAG=p1s

This requires a small patch to the sendmail init.d script, which I'll
attach next.


Comment 2 James Ralston 2004-06-28 06:54:06 UTC
Created attachment 101458 [details]
patch for sendmail init.d script

Comment 3 Suzanne Hillman 2004-08-09 15:40:12 UTC
Internal RFE bug #129473 entered; will be considered for future releases.

Comment 6 Thomas Woerner 2004-10-19 09:35:05 UTC
Closing as "WONTFIX".

Comment 7 James Ralston 2004-10-20 22:09:17 UTC
Why?

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

Versus:

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 18:33:21 UTC
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 19:20:10 UTC
REOPENED status has been deprecated. ASSIGNED with keyword of Reopened is preferred.

Comment 10 Thomas Woerner 2007-07-23 09:44:20 UTC
This has been fixed for RHEL-4+

Comment 11 Thomas Woerner 2007-07-24 15:57:52 UTC
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
defects.

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.