| 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 | |
| | 243 | 17: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 | }}} |
| | 247 | Note 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 | {{{ |
| | 249 | 477 ippc91 OFF 0.0.0.bf |
| | 250 | 478 ippc91 OFF 0.0.0.f9 |
| | 251 | 479 ippc91 OFF 0.0.0.133 |
| | 252 | 480 ippc91 OFF 0.0.0.16d |
| | 253 | 481 ippc91 OFF 0.0.0.1a7 |
| | 254 | }}} |
| | 255 | At this point maintenance can go ahead on the machine. |
| | 256 | |
| | 257 | To 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 | |
| | 262 | First, see if I can cleanup all the ps_ud_WEB stuff: |
| | 263 | i) query the faulted jobs to get chip/warp ids |
| | 264 | ii) send them to cleaned (both chip and warp) |
| | 265 | iii) Once cleaned set them to update |
| | 266 | |
| | 267 | Next there are a lot of stuck jobs under the update.LAP.PV3 label. Repeat the process of: |
| | 268 | i) send them all to clean |
| | 269 | ii) once cleaned send them to update (I put them under ps_ud_WEB since there is nothing there now) |
| | 270 | |
| | 271 | This solved the majority of issues, about 437 of them, leaving only 4 problems, which shall be dealt with tomorrow. |
| | 276 | '''stamp request is stuck''' by JRF |
| | 277 | |
| | 278 | So check it out: |
| | 279 | {{{ |
| | 280 | pstamptool -dbname ippRequestServer -dbserver ipp113 -pendingdependent -simple |
| | 281 | |
| | 282 | 10977094 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 | |
| | 285 | Query it: |
| | 286 | {{{ |
| | 287 | SELECT |
| | 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 | |
| | 310 | Update the run to a higher priority label, and set it to update: |
| | 311 | {{{ |
| | 312 | chiptool -dbname gpc1 -updaterun -chip_id 1488053 -state update -set_label ps_ud_MOPS |
| | 313 | warptool -dbname gpc1 -updaterun -warp_id 1436300 -state update -set_label ps_ud_MOPS |
| | 314 | chiptool -dbname gpc1 -setimfiletoupdate -set_label ps_ud_MOPS -chip_id 1488053 |
| | 315 | warptool -dbname gpc1 -setskyfiletoupdate -set_label ps_ud_MOPS -warp_id 1436300 |
| | 316 | }}} |
| | 317 | |
| | 318 | |
| | 319 | '''Broken jobs''' by JRF |
| | 320 | |
| | 321 | Continuing on from yesterday, I sent around 400 unique jobs to clean -> then update. The majority of this proceeded successfully! |
| | 322 | There 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 | }}} |
| | 326 | The 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 | |
| | 328 | So, fetch the jobs that have the issue: |
| | 329 | {{{ |
| | 330 | SELECT |
| | 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 | }}} |
| | 352 | The 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 | |
| | 360 | Wait for them to finish processing... |
| | 361 | |
| | 362 | Looks like problems (in the chip and cam stage): |
| | 363 | They'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 | |
| | 365 | Once 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 | |
| | 374 | ITC are going to install the PDUs in ipp134-136, so these will need to be set to down: |
| | 375 | neb-host ipp134 down --note "JRF: repair -> down: so that PDU can be installed in the cabinet" |
| | 376 | neb-host ipp135 down --note "JRF: repair -> down: so that PDU can be installed in the cabinet" |
| | 377 | neb-host ipp136 down --note "JRF: repair -> down: so that PDU can be installed in the cabinet" |
| | 378 | set down at about 09:20am |
| | 379 | |
| | 380 | |
| | 381 | |
| | 382 | TODO: |
| | 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 | |