[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Perl: CmdSchedule
> 1) Who do to these scripts run as? Does it need to vary (ie, does my
> script need to be suid root?)
No... we should create a "linuxkb" user on the system... and all scripts
should run as that user... and I will set up it's enviroment, etc. to
authenticate properly with MySQL.
> 2) Howabout a "email" (text) and "notify" (enum('y','n')) fields? That
> way people can get an email of output or sucess/failure if they choose. I
> know you suggest we do this later, but I'd rather do this as part of v1.0
Hm. I was thinking of something more general... such as build into the
script eventually or now... to just shoot off a mail when it marks
something as failed... or maybe we don't care if certain things failed is
perhaps what your saying? That is a possibility... and I could add an
enum field for that... and just defualt it to always notify on failure...
but have the functions make it possible to turn it off... but not sure
what the email (text) would do...
I envision the scheduling system used a LOT eventually... and I'm having a
hard time envisioning anyone coding into there php pages an email to
kickoff everytime somone performs a certain action...
But I could be totally wrong and smoking something bad :). Do you think a
generic failure notification that can be turned on/off is good enough in
which case I'll add a notify enum field? Or do we want more control than
that?
> On Tue, 16 Nov 1999, Jason Pincin wrote:
>
> > This email is primarily directed towards Aaron, but the group is
> > encouraged to look over it, and if any of you are interested in helping do
> > this, contact Aaron.
> >
> > CmdSchedule:
> >
> > The purpose of the table now in the linuxkb database called CmdScedule is
> > to allow the forming directory and php interfaces to easily
> > schedule external commands, and easily interact with non php code. I
> > encourage you to look at the CmdSchedule table while reading this.
> >
> > How I think it should work is:
> >
> > Every minute a perl script will query the CmdSchedule table to see if
> > there are any commands to be executed. If there are, the perl script will
> > call those commands, passing object ID's as parameters of those commands.
> > You'll notice the table closely resembles crontab. In addition to
> > allowing an easy way for the objects to schedule outside tasks, etc. buy
> > taking this approach we allow ourselves to improve this perl script once
> > working, in order to allow it to optimize execution. For example... If
> > evberything were to be done immediatly instead of scheduled... you may
> > have this situation:
> >
> > 10 people logged on all submitting questions that are to be processed and
> > mailed out via the mail connector, as well as posted via the web. This
> > involves 10 processes to do the mailing all unaware of each other, 10
> > submits, etc.
> >
> > If we do this via scheduling, all 10 get logged into the CmdSchedule table
> > as immediate actions, and when the query is run, it will see 10 identical
> > actions... instead of forking 10 processes, it can just combine the
> > targeted objects and pass them as 10 parameters into the mailer.
> >
> > Thats just one example - there's a ton more we could eventually do to
> > optimize things... but for now - we just need to get it working. So -
> > here is the SQL command to identify what commands are to br run now (at
> > the minute the perl script runs):
> >
> > select CmdID, CmdType, CommandPath, TargetObjects, Attempts from
> > CmdSchedule,
> > ExternalCommands where CmdSchedule.CommandID = ExternalCommands.CommandID
> > and (Status != 'Disabled' and Status !='Failed' and Status != 'Running')
> > and ( (CmdType = 'Immediate' OR Status = 'PendingRetry') OR ( (Hour = '*'
> > OR Hour = 'this hour') AND
> > (Minute = '*' OR Minute = 'this minute') AND (WeekDay = '*' OR WeekDay =
> > 'this day of week') AND (MonthDay = '*' OR MonthDay = 'this dat of month')
> > ) );
> >
> > You'll need to come up with ways to do various things... but I'm designing
> > the whole thing... so... if ya run into sql issues lemme know.
> >
> > I was thinking after the select, when you have your list of commands, you
> > should update the table and set matching CmdID's to a status of 'Running'.
> > If a command fails for any reason you would increment the Attempts by 1,
> > and set staus to 'PendingRetry'. The sql statement above would always
> > return record's who's CmdType is immediate or status is PendingRetry
> > regardless of scheduled time.
> >
> > Once Attempts count hits 3 or whatever, it should be set to Status =
> > 'Failed' which will stop it from being returned. Later we can worry about
> > a way to notify ourselves of failures, and how frequently they'll be
> > purged.
> >
> > Don't know if I left anything out... please mail me if I have.
> >
> > Obviously, the command you'll call will be contained in the CommandPath
> > field, and TargetObjects will be passed to that command as parameters.
> >
> > I'll be doing the php code to poulate this table... perl just has to read
> > it and do what it says... any other thoughts?
> >
> > They're very welcome...
> >
> > --
> > Jason
> > http://vodka.linuxkb.org/~chardros
> >
>
> --
> Aaron Turner, Core Developer http://vodka.linuxkb.org/~aturner/
> Linux Knowledge Base Organization http://linuxkb.org/
> Because world domination requires quality open documentation.
--
Jason
http://vodka.linuxkb.org/~chardros