Re: 2.99.55 scheduler.conf parsing problem

[Matti Aarnio <mea@nic.funet.fi>]

On Thu, May 17, 2001 at 07:11:54AM +0100, Darryl Miles wrote:
> Is there a bug in the scheduler.conf parsing for the LAST entry
> 'command' setting?
> 
> I have switched on -v -v and the 'read' statement show it reads
> 'command="sm -8c $channel multidrop"' but when the full config is dumped
> immediatly afterwards it shows:
> 
>         command hold
>         argv[0] = hold
> 
> All mail going to this channel gets processed once and then stays in the
> queue/transport spool going nowhere.  If I restart the scheduler it will
> pick them all back up and, process them once and again they go nowhere.

 Oh ?  I don't see that repeating myself.
 Could you send me your  scheduler.conf  ??

 I have systems with following two last groups:

read 'bitbucket/*' 1
read 'maxchannel=1' 0
read 'command="sm -c $channel bitbucket"' 0
read 'smtpgw-*/*' 1
read 'maxchannel=30' 0
read 'maxring=30' 0
read 'command="sm -8c $channel $channel"' 0

 which appear as these in the config dump:

bitbucket/* 0xbfffd5c8
        command sm
        argv[0] = sm
        argv[1] = -c
        argv[2] = $channel
        argv[3] = bitbucket
smtpgw-*/* 0xbfffd5c8
        command sm
        argv[0] = sm
        argv[1] = -8c
        argv[2] = $channel
        argv[3] = $channel

  The "command" pointed string is split, and argv[] points to its
  internal parts with '\000' bytes separating them.
  That is why you won't see the real unmodified input data there..

> To work around the problem I have put in a bung channel entry AFTER the
> last one in the config, so that get inflicked with the bug.

  Your machine, and compiler are ?

> Regards,
> -- 
> Darryl Miles

-- 
/Matti Aarnio	<mea@nic.funet.fi>