Changes between Version 50 and Version 51 of PS1_IPP_CzarLog_20110103

Timestamp:

Jan 7, 2011, 1:30:51 PM (15 years ago)

Author:

Serge CHASTEL

Comment:

--

PS1_IPP_CzarLog_20110103

@@ -85 +85 @@
  * (serge) 08:39 chip.on, warp.on, stack.on
  * (serge) 09:58 I had to queue the last 3 MD02 exposures for publishing by hand (pubtool -definerun -client_id 1 -label MD02.nightlyscience -dbname gpc1). The weirdest is that I had to enter the command three times. The first command only queued the first missing exposure (o5568g0132o MD02 z N5568 MD02 center). Successive calls to (pubtool -definerun -client_id 1 -label MD02.nightlyscience -dbname gpc1) didn't add the missing exposures? I had to wait for the first missing exposure to be published to be able to add the second one (same for the third exposure)
+ * (from bill) 12:36 Rather than try and figure out what's wrong with nightly science (I think it's confused about the states)
+
+pantasks: ns.show.dates
+2011-01-02 NEW FINISHED_STACKS FINISHED_DIFFS END_OF_NIGHT
+2011-01-01 NEW FINISHED_STACKS FINISHED_DIFFS END_OF_NIGHT
+2011-01-05 NEW FINISHED_STACKS FINISHED_DIFFS END_OF_NIGHT
+2010-11-04 NEW FINISHED_STACKS FINISHED_DIFFS END_OF_NIGHT
+2011-01-06 NEW FINISHED_STACKS FINISHED_DIFFS END_OF_NIGHT
+2011-01-07 NEW FINISHED_STACKS FINISHED_DIFFS END_OF_NIGHT
+
+I ran
+   nightly_science.pl --queue_stacks --date 2011-01-07 --dbname gpc1
  * (bills) 12:41 set all pantasks to stop in preparation for doing Build install in ippScripts of the production build. Then did the build, then restarted. These changes should prevent registration from getting stuck due to bad data_state/burntool_state.
  * (bills) 13:00 Changed Label priorities back for requests that come in from the WEB form. The M31 request still has 562 jobs to go but other requests have started to come in from the form so I want to let them have a chance. I think that I need to get trickier with the labels. Maybe use WEB.HOG if a request generates too many jobs.