211c215c654c363993a9d480cbda679de0bbd7e9 hiram Fri May 1 13:59:15 2026 -0700 eliminating stderr information to avoid cron job noise refs #31811 diff --git src/hg/utils/otto/userRequests/README.txt src/hg/utils/otto/userRequests/README.txt index f847635fefa..7c8adc8511a 100644 --- src/hg/utils/otto/userRequests/README.txt +++ src/hg/utils/otto/userRequests/README.txt @@ -29,43 +29,48 @@ For example: *************************** 1. row *************************** id: 1 requestType: liftOver fromDb: GCF_000260355.1 toDb: GCF_004115215.2 email: nullmodel@gmail.com comment: testing the galaxy pipeline, from: star-nosed mole (GCF_000260355.1), to: platypus (Pmale09 v4 2020) (GCF_004115215.2) requestTime: 2026-04-23 15:20:19 status: 0 buildDir: completeTime: NULL ############################################################################ ### 2. +### cron entry in the otto user: +# 1,8,15,22,29,36,43,50,57 * * * * /hive/data/outside/otto/liftRequest/ottoRequest.py +### ottoRequest.py - otto user cron job running each minute to watch the - ottoRequest table in hgcentral. Watches for two types of - entries: liftRequest and assembly - when new entries are - detected (status==0) it marks the table entry as - pending (status=1) and sends - out notification emails, one to the requesting user and - Bcc to either chain-file-request-group@ucsc.edu for liftRequest - or Bcc genark-request-group@ucsc.edu for assembly requests. - The From and Return-To addresses are genome-www@soe.ucsc.edu - and I believe that will receive bounces from bad user addresses ############################################################################ ### 3. +#9,20,31,42,53 * * * * ~/kent/src/hg/utils/otto/userRequests/ottoRequestWatch.sh +### ottoRequestWatch.sh - cron script running in hiram hgwdev account to watch - the ottoRequest table. When new entries show - up (status=1) it will get the galaxy workflow - running by using ottoRequestAlign.sh to construct the - kegAlignLastz.sh script arguments and starts that process. - ottoRequestAlign.sh will set 'status=2' as the galaxy WF is on. - Uses workflowMonitor.sh to check the status of jobs that - are in 'status=2' state, when the galaxy run is complete, - will set 'status=4' - when it detects 'status=4' state, it will construct the - symlinks to get all the files ready for pushing and it - makes the entries in liftOverChain and quickLiftChain tables. - and then it sets 'status=5' - the 'status=5' states are detected by the - ottoRequestPush.py cron job - which does the business of @@ -108,23 +113,26 @@ the job of getting the galaxy WF running. The monitoring of the WF and the download of the results takes place in the other scripts. ############################################################################ ### 6. workflowMonitor.sh - after the galaxy WF has started, this script can - check the status of the job and if it is done, then - the processing of the results will take place to - construct the chain files. - can set status to: - 7 == problems - 3 == galaxy finished ############################################################################ ### 7. +### cron entry in hiram crontab: +# 4,26,46 * * * * ~/kent/src/hg/utils/otto/userRequests/ottoRequestPush.py +### ottoRequestPush.py - cron job watching for status == 5 - will run the pushing procedure for the relevant assemblies. When complete will set status = 6 TBD: Need to figure out how to push the UCSC database files out ############################################################################ ### 8. galaxyCleanup.py - used by ottoRequestWatch.sh to release all the data from galaxy after everything is complete.