Bug 126760

Summary: [PATCH] method to specify persistent queue runners?
Product: Red Hat Enterprise Linux 3 Reporter: James Ralston <ralston>
Component: sendmailAssignee: Thomas Woerner <twoerner>
Status: CLOSED WONTFIX QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 3.0CC: shillman
Target Milestone: ---Keywords: FutureFeature, Reopened
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-07-24 15:58:21 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 200921    
Attachments:
Description Flags
patch for sendmail init.d script none

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.