[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[GEMPAK #WKD-232184]: Competing GEMPAK-related cron jobs
- Subject: [GEMPAK #WKD-232184]: Competing GEMPAK-related cron jobs
- Date: Fri, 27 Apr 2007 10:30:45 -0600
Jeff,
The cleanup script is configured to run on a per user basis, so it will kill
any gplt processes and children of currently running scripts. It was intended
to be a way to quickly remove the message queues,gplts,and children when things
went bad, rather than used regularly during your product generation.
The only suggestion I have is to have all of your scripts (or a master script
launcher)
touch a /tmp/.gemlock.$$ file where $$ is the script process ID, and then
remove that file
when the script is finished.
The launching of the cleanup script could be modified to check for any files of
the name
/tmp/.gemlock.$$ and if found, either exit with a note to the user, or go into
a sleep loop.
You could also have the cleanup launching script touch a /tmp/.cleanuplock file
on startup, that
product generation launching scripts would check for, and they would wait until
that lock file was
removed at the end of cleanup. If you did this in a launcher script, then you
wouldn't have to
worry about modifying lots of scripts, or the distributed cleanup script.
I use a type of file semaphore/lock system in LDM generation scripts to prevent
multiple
copies of the same script from running when a slew of back data arrives (eg
starting
the LDM with an empty queue and catching up on 1 hour's worth of data in a few
seconds).
The the "sleep" loop lasts for more than a specified number of cycles, I send
an
email to myself to check on any problems.
Steve Chiswell
Unidata User Support
>
> Hi,
>
> If you have 3 different cron jobs using GEMPAK programs, we have noticed
> times when 2 or 3 different GEMPAK programs are running at the same time
> (by the same user) and if you use the cleanup command it removes all msg
> queues and at times corrupts one of the other GEMPAK jobs still going on.
> Is there a way to stay away from this potential conflict while using the
> same user account? If you need more info, let me know. Thanks!
>
>
> Jeffrey M. Vukovich
> Senior Research Scientist
> Baron Advanced Meteorological Systems
> 920 Main Campus Drive
> Suite 101
> Raleigh, NC 27606
> Phone: (919) 424-4442
> Mobile: (256) 541-4138
> Fax: (919) 424-4401
> Email: address@hidden
>
>
Ticket Details
===================
Ticket ID: WKD-232184
Department: Support GEMPAK
Priority: Normal
Status: Closed