IPP Software Navigation Tools IPP Links Communication Pan-STARRS Links

Changes between Version 6 and Version 7 of PS1_IPP_Czarlog_20190426


Ignore:
Timestamp:
Apr 30, 2019, 11:04:13 AM (7 years ago)
Author:
fairlamb
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • PS1_IPP_Czarlog_20190426

    v6 v7  
    219219
    220220
    221 '''Broken update stuff (continued)'''
     221'''Broken update stuff (continued)''' by JRF
    222222
    223223a broken job in the ps_ud_WEB chip stage:
     
    239239
    240240
    241 
    242 
    243 
    244 To do:
    245  - Once ipp134-139 are back online revert the mopsfix job stuck in the camera stage
    246  - send everything in update.LAP.PV3 to clean...
    247  - ...once cleaned, send them all to update. This should fix most of the chip issues
    248  - For the remaining problems:
    249     -- if they complain about missing cm (camera) files then they should be reprocessed.
     241'''Hardware stuff update'' by JRF
     242
     24317:00 - Haydn wishes to replace some failing drives on some of the compute nodes (ippc91, ippc52, ippc53, and ippc85). To allow him to do this the nodes need to be turned off in pantasks; e.g. to turn off ippc91:
     244{{{
     245  check_system.sh hostoff ippc91
     246}}}
     247Note that this needs to be done for as many times as the machine appears in the controller list (pantasks> controller status). Once done sufficient times, and allowing some time for jobs to finish if they were in use, then they should all report as 'OFF', for example:
     248{{{
     249477  ippc91    OFF  0.0.0.bf
     250478  ippc91    OFF  0.0.0.f9
     251479  ippc91    OFF  0.0.0.133
     252480  ippc91    OFF  0.0.0.16d
     253481  ippc91    OFF  0.0.0.1a7
     254}}}
     255At this point maintenance can go ahead on the machine.
     256
     257To see which nodes are used by which pantasks check the '~ippitc/ippconfig/pantasks_hosts.input' file. None of the main tasks use c52 or c53. MEH has confirmed that they are off for the mops stdscience stuff.
     258
     259
     260''' Geet big cleanup and process ''' by JRF
     261
     262First, see if I can cleanup all the ps_ud_WEB stuff:
     263i) query the faulted jobs to get chip/warp ids
     264ii) send them to cleaned (both chip and warp)
     265iii) Once cleaned set them to update
     266
     267Next there are a lot of stuck jobs under the update.LAP.PV3 label. Repeat the process of:
     268i) send them all to clean
     269ii) once cleaned send them to update (I put them under ps_ud_WEB since there is nothing there now)
     270
     271This solved the majority of issues, about 437 of them, leaving only 4 problems, which shall be dealt with tomorrow.
    250272
    251273 
    252274=== Tuesday : 2019.04.30 ===
    253275
     276'''stamp request is stuck''' by JRF
     277
     278So check it out:
     279{{{
     280pstamptool -dbname ippRequestServer -dbserver ipp113 -pendingdependent -simple
     281
     28210977094 new warp 1436300 skycell.0750.010 gpc1 /data/ipp113.0/pstamp/work/2019/04/30/920240 ps_ud_MOPS F 0 0 MOPS 920240 /data/ipp113.0/pstamp/work/2019/04/30/920240/checkdep.10977094.log 500
     283}}}
     284
     285Query it:
     286{{{
     287SELECT
     288  rawExp.exp_name,rawExp.exp_id,
     289  chipRun.chip_id,
     290  warpRun.warp_id,warpSkyfile.skycell_id,warpRun.state,warpRun.label,
     291  warpSkyfile.path_base
     292 FROM
     293  warpSkyfile, warpRun, fakeRun, camRun, chipRun, rawExp
     294 WHERE
     295  warpSkyfile.warp_id = warpRun.warp_id AND warpRun.fake_id = fakeRun.fake_id AND fakeRun.cam_id = camRun.cam_id AND camRun.chip_id = chipRun.chip_id AND chipRun.exp_id = rawExp.exp_id
     296 AND
     297  warpRun.warp_id = '1436300'
     298 AND
     299  warpSkyfile.skycell_id like 'skycell.0750.010'
     300  ;
     301
     302
     303+-------------+--------+---------+---------+------------------+--------+----------------+
     304| exp_name    | exp_id | chip_id | warp_id | skycell_id       | state  | label          |
     305+-------------+--------+---------+---------+------------------+--------+----------------+
     306| o6284g0630o | 558924 | 1488053 | 1436300 | skycell.0750.010 | update | update.LAP.PV3 |
     307+-------------+--------+---------+---------+------------------+--------+----------------+
     308}}}
     309
     310Update the run to a higher priority label, and set it to update:
     311{{{
     312chiptool -dbname gpc1 -updaterun -chip_id 1488053 -state update -set_label ps_ud_MOPS
     313warptool -dbname gpc1 -updaterun -warp_id 1436300 -state update -set_label ps_ud_MOPS
     314chiptool -dbname gpc1 -setimfiletoupdate -set_label ps_ud_MOPS -chip_id 1488053
     315warptool -dbname gpc1 -setskyfiletoupdate -set_label ps_ud_MOPS -warp_id 1436300
     316}}}
     317
     318
     319'''Broken jobs''' by JRF
     320
     321Continuing on from yesterday, I sent around 400 unique jobs to clean -> then update. The majority of this proceeded successfully!
     322There are a handful (about 60 failures, only 3-4 unique chip/warp combos) that are still failing. Checking their log it complains about a missing file of the form:
     323{{{
     324    *cm*.XY*.mk.fits
     325}}}
     326The cm indicates that this is from the camera stage. Because of this updating the chip or warp stage will not help, we have to reprocess instead.
     327
     328So, fetch the jobs that have the issue:
     329{{{
     330SELECT
     331 rawExp.exp_name,rawExp.exp_id,rawExp.filter,
     332 chipRun.chip_id,warpRun.warp_id,warpSkyfile.skycell_id,warpRun.state,warpRun.label,warpSkyfile.fault
     333 FROM
     334 warpSkyfile, warpRun, fakeRun, camRun, chipRun, rawExp
     335 WHERE
     336 warpSkyfile.warp_id = warpRun.warp_id AND warpRun.fake_id = fakeRun.fake_id AND fakeRun.cam_id = camRun.cam_id AND camRun.chip_id = chipRun.chip_id AND chipRun.exp_id = rawExp.exp_id
     337 AND warpSkyfile.fault != 0
     338 AND warpRun.label like 'ps_ud_WEB'
     339 GROUP BY warpRun.warp_id
     340;
     341
     342+-------------+--------+---------+---------+------------------+--------+-----------+-------+
     343| exp_name    | exp_id | chip_id | warp_id | skycell_id       | state  | label     | fault |
     344+-------------+--------+---------+---------+------------------+--------+-----------+-------+
     345| o5794g0540o | 380413 | 1335129 | 1285254 | skycell.2501.030 | update | ps_ud_WEB |     2 |
     346| o5576g0112o | 280226 | 1335126 | 1285655 | skycell.2457.094 | update | ps_ud_WEB |     2 |
     347| o6575g0385o | 664527 | 1335259 | 1286115 | skycell.2353.026 | update | ps_ud_WEB |     2 |
     348| o6237g0252o | 545358 | 1335251 | 1286194 | skycell.2352.010 | update | ps_ud_WEB |     2 |
     349| o6302g0235o | 565722 | 1335991 | 1288841 | skycell.2169.079 | update | ps_ud_WEB |     4 |
     350+-------------+--------+---------+---------+------------------+--------+-----------+-------+
     351}}}
     352The fault 4 can just be reverted. As for the others, send them to reprocess:
     353{{{
     354    chiptool -dbname gpc1 -definebyquery -set_label mopsfix  -set_workdir neb://@HOST@.0/gpc1/mops.fixbrokenLAP.20190430  -set_dist_group NULL -set_tess_id RINGS.V3 -set_end_stage warp -set_data_group mops.fixbrokenLAP.20190430 -set_reduction LAP_SCIENCE -exp_name o5794g0540o
     355    chiptool -dbname gpc1 -definebyquery -set_label mopsfix  -set_workdir neb://@HOST@.0/gpc1/mops.fixbrokenLAP.20190430  -set_dist_group NULL -set_tess_id RINGS.V3 -set_end_stage warp -set_data_group mops.fixbrokenLAP.20190430 -set_reduction LAP_SCIENCE -exp_name o5576g0112o
     356    chiptool -dbname gpc1 -definebyquery -set_label mopsfix  -set_workdir neb://@HOST@.0/gpc1/mops.fixbrokenLAP.20190430  -set_dist_group NULL -set_tess_id RINGS.V3 -set_end_stage warp -set_data_group mops.fixbrokenLAP.20190430 -set_reduction LAP_SCIENCE -exp_name o6575g0385o
     357    chiptool -dbname gpc1 -definebyquery -set_label mopsfix  -set_workdir neb://@HOST@.0/gpc1/mops.fixbrokenLAP.20190430  -set_dist_group NULL -set_tess_id RINGS.V3 -set_end_stage warp -set_data_group mops.fixbrokenLAP.20190430 -set_reduction LAP_SCIENCE -exp_name o6237g0252o
     358}}}
     359
     360Wait for them to finish processing...
     361
     362Looks like problems (in the chip and cam stage):
     363They're all waiting on some files that are only on ipp134-136 - I just set these down so that ITC could install the PDU. PENDING
     364
     365Once good, cleanup remaining files:
     366{{{
     367    chiptool -dbname gpc1 -updaterun -set_state goto_cleaned -set_label goto_cleaned -chip_id
     368    warptool -dbname gpc1 -updaterun -set_state goto_cleaned -set_label goto_cleaned -warp_id
     369}}}
     370
     371
     372'''Morning hardware things''' by JRF
     373
     374ITC are going to install the PDUs in ipp134-136, so these will need to be set to down:
     375neb-host ipp134 down --note "JRF: repair -> down: so that PDU can be installed in the cabinet"
     376neb-host ipp135 down --note "JRF: repair -> down: so that PDU can be installed in the cabinet"
     377neb-host ipp136 down --note "JRF: repair -> down: so that PDU can be installed in the cabinet"
     378set down at about 09:20am
     379
     380
     381
     382TODO:
     383 - once the PDU is done for ipp134-136:
     384   -- check the console
     385   -- put them to up to allow updates to continue and check on them
     386
     387
    254388=== Wednesday : 2019.05.01 ===
    255389