lr_run and lr_spoold (was: Re: [COMMIT LOGREPORT] service/all/lib/Lire Program.pm,1.3,1.4)

[Joost van Baal]

Hi,

On Mon, Aug 27, 2001 at 10:00:35PM -0400, Francis J. Lacoste wrote:
> On Mon, Aug 27, 2001 at 11:42:12PM +0200, Joost van Baal wrote:
> > On Sun, Aug 26, 2001 at 11:32:39AM -0700, Francis J. Lacoste wrote:
> > > 
> > > 	Program.pm 
> > > Log Message:
> > > All scripts that use Lire::Program now log performance data
> > > and their command line argument.
> > 
<snip>
> > BTW, do we still need lr_run?  What's your opinion on this?
> > 
> 
> Personnally, I'm not totally happy with the fact that we have to
> use lr_run to run most programs. 

I expected that.... ;-)

> But we still currently need it, because
> a huge bulk of Lire configuration is done in the defaults configuration
> file which is a shell script that we source.  So we need lr_run to have 
> the environment variables properly setup. 
> 
> I could think of an awfull hack to parse defaults from perl using something
> like 
> 
> open ( DEFAULTS, "sh -e 'source /etc/lire/defaults && env |")
>     or die "open: $!\n";
> while ( <DEFAULTS ) {
>    chomp;
>    my ( $name, $value ) = /^(\w+)=(.*)$/;
>    $ENV{$name} = $value;
> }
> close DEFAULTS;
> 
> This could be made part of Lire::Program, but I'm not sure it's a nice
> alternative to lr_run.

Nah... too awfull imho.

> What do you think ? If we go with this, it's easy to add to Lire::Program
> the setting of logging policy according to the configuration variables. There
> is a Syslog interface which is part of perl.

The decision we gotta take is wether we want to keep running shell scripts
which call perl scripts.  I like such a setup, and prefer it to have
perl scripts call perl functions, since it makes it easy to run small
parts of the system standalone.  This is very valuable when debugging.

I would _never_ write a perl script to parse a shell script.  I'd prefer
to get rid of etc/lire/defaults, and re-implement it as something easily
parsable by perl.  But I guess my favourite solution is to stay with
lr_run as a shell script.  lr_run can be used as a wrapper for both
shell and perl scripts, which is a nice thing.

Next to easy debugging, an advantage of shell scripts is the fact they're
more widely known.  There are more sysadmins who know how to tweak a shell
script than who know how to tweak a perl script.  Having etc/lire/defaults
in shell syntax is nice, in this respect, as is in having shell scripts
at the 'outside' of the system.

> 
> BTW, what do you think of turning lr_spoold into a proper daemon. This is
> easy to do in perl ?

As a historical note:  The first Lire release
(that was about April 2000) used maildircmd (
http://www.nb.net/~lbudney/linux/software/maildircmd.html ) to process
the maildirs.  The fact this software relies on djbware doesn't make it
very attractive for a wide audience, however.

I would like to stick with processing the maildir's periodically (so:
not processing a message rightaway when it is delivered).  Of course,
a proper daemon could do this.  If reimplementing it in perl makes it
more reliable (and doesn't need a lot of external CPAN perl modules),
than go ahead.  BTW: are you suggesting to reimplement lr_spool also?

Bye,

Joost


-- 
To UNSUBSCRIBE, email to development-request at logreport.org with a subject of
"unsubscribe". Trouble? Send an email with subject "help" to
development-request at logreport.org