Re: 2.99.55 scheduler.conf parsing problem

[Darryl Miles <darryl@netbauds.net>]

Matti Aarnio wrote:
> 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..



************************************************************************
--- zmailer-2.99.55/scheduler/readconfig.c~     Fri Feb 16 08:22:53 2001
+++ zmailer-2.99.55/scheduler/readconfig.c      Thu May 24 23:04:50 2001
@@ -407,6 +407,7 @@

 redo_readtoken:
        if (lp == NULL) {
+         memset (line, 0, sizeof line);
          if (csfgets(line, sizeof line, fp) < 0)
            return -1;
          *linenump += 1;
************************************************************************

The TABs have probably been lost in the above patch.


Basically end your config with the following sequence:

************* CUT HERE ***************
#	command=hold
	
************* CUT HERE ***************

That is a HASH (comment mark), a TAB, the sequence "command=hold", an
EOL sequence.
Then a TAB (or I think a space will also work) but NO EOL sequence.

Basically the last character in the file is not an EOL sequence.


This causes the function readtoken() in readconfig.c of scheduler to
read in the next line overwriting the previous buffer (char
line[BUFSIZ]), however since there is no EOL sequence no '\0' is
written.  Therefore the previous config entry becomes visible in the
resultant string and thus parsed.

I'm not sure if my fix is correct, but as I can't see anyway of the
fgets() like function to return if an EOL sequence was found or not it
seems like the easiest way.

-- 
Darryl Miles

Webtraffik Netbauds Ltd
www.netbauds.net