Re: CmdSchedule.pl

[Jason Pincin <chardros@linuxkb.org>]

> Bad news is that I've been sick all weekend.  Good news is that I had

Sorry to hear that man!

> 1) I detect failure by the exit code or the inability to execute the
> command.  For now, any non-zero exit code is a failure.  So besure your
> scripts properly set the exit code.

k

> 2) What to do with output (STDOUT) and the exit code once I get it?
> There's no place to put it in the DB.  Not sure if we want a log file or
> an email or something.  Or just ignore the output and don't save it
> anywhere.  For now, output goes to the email, but this is far from perfect
> since this is a forking app so lines of output from different children
> may be mixed together making reading/debugging difficult.

Originally, we were just going to email STDOUT if an email address was given for
the command, otherwise, pipe stdout to /dev/null or whatever.

A log table IS a good idea, and something I could slap together quick if you
could impliment it equally quickly.  Your call.  Email is good enough for now -
I'm sure we'll want a DB log at some point... so if yur up for handling it now,
we can do a table... if not, we'll just hold off and impliment it later.  Your
call.  Lemme know.  But we definately need the email.

> 3) There's something about forking and DB access in the same script that
> causes disconnects from the DB for no apparent reason sometimes.  I've got
> a ugly hack in place to patch this bug... not perfect but it seems to work
> well.

Hrm.  Wierd.

> 4) The only thing left to do is make it so that the timer works.  Which
> reminds me- if a timer expires before the command is done, and the app is
> killed off, how should the database be updated to reflect that?

I'd say "Failed" with an email sent out describing the fact that the command went
over limit.  

-- 
Jason Pincin
Linux Knowledge Base Project Leader (http://www.linuxkb.org/)
http://vodka.linuxkb.org/~chardros/