[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[GEMPAK #WKD-232184]: Competing GEMPAK-related cron jobs

This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.

  • 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