Page History
...
This section is to help troubleshoot any errors.
L1Proc failing
If the L1Proc deliveries start to fail after the calibration change takes effect, look at the logs mentioned above and search for any errors. If you see something like:
...
was all that was needed to successfully process the delivery.
Duplicate rows
During one update, step 20 was done twice creating two rows in the database, and the vend value was not updated for the "old" calibration file. The calibrator uses does not have permission to delete rows. What you can do is edit the value in the table to manually set either using the rdbGUI (like in step 20) or logging into the database on the command line.
Here's what was done on the command line. First, log into the mysql database. I think this works from pretty much any SLAC machine. The password is the same as the one used for rdbGUI given above:
mysql -h glastCalibDB.slac.stanford.edu -u calibrator -p
Then change to the calib database and look at the table. Below are the last few entries for the TKR calibration files:
| Code Block | ||
|---|---|---|
| ||
MySQL [(none)]> use calib;
MySQL [calib]> select ser_no,flavor,data_ident,vstart,vend,update_time from metadata_v2r1 where calib_type = 'TKR_DeadChan' and ser_no > 1256;
+--------+-----------+------------------------------------------+---------------------+---------------------+---------------------+
| ser_no | flavor | data_ident | vstart | vend | update_time |
+--------+-----------+------------------------------------------+---------------------+---------------------+---------------------+
| 1263 | L1current | $(LATCalibRoot)/TKR/LAT_BadStrips_58.xml | 2020-08-03 15:30:00 | 2020-11-05 04:23:00 | 2020-11-05 02:28:20 |
| 1267 | L1current | $(LATCalibRoot)/TKR/LAT_BadStrips_59.xml | 2020-11-05 04:23:00 | 2021-02-03 15:41:00 | 2021-02-03 20:28:28 |
| 1271 | L1current | $(LATCalibRoot)/TKR/LAT_BadStrips_60.xml | 2021-02-03 15:41:00 | 2037-01-01 00:00:00 | 2021-02-03 20:28:28 |
| 1278 | L1current | $(LATCalibRoot)/TKR/LAT_BadStrips_61.xml | 2021-05-04 18:29:00 | 2037-01-01 00:00:00 | 2021-05-04 22:09:54 |
| 1279 | L1current | $(LATCalibRoot)/TKR/LAT_BadStrips_61.xml | 2021-05-04 18:30:00 | 2037-01-01 00:00:00 | 2021-05-04 21:45:51 |
+--------+-----------+------------------------------------------+---------------------+---------------------+---------------------
|
I then updated the vend times the "old" one and the initial duplicate. For good measure, I also changed the flavor of the 1278 row to "test" from "L1current" since the pipeline selects only "L1current" files (see the note in step 25e).
| Code Block | ||
|---|---|---|
| ||
MySQL [calib]> update metadata_v2r1 set vend = '2021-05-04 18:30:00' where ser_no = 1271;
MySQL [calib]> update metadata_v2r1 set vend = '2021-05-04 18:30:00' where ser_no = 1278;
MySQL [calib]> update metadata_v2r1 set flavor='test' where ser_no = 1278;
MySQL [calib]> select ser_no,flavor,data_ident,vstart,vend,update_time from metadata_v2r1 where calib_type = 'TKR_DeadChan' and ser_no > 1256;
+--------+-----------+------------------------------------------+---------------------+---------------------+---------------------+
| ser_no | flavor | data_ident | vstart | vend | update_time |
+--------+-----------+------------------------------------------+---------------------+---------------------+---------------------+
| 1263 | L1current | $(LATCalibRoot)/TKR/LAT_BadStrips_58.xml | 2020-08-03 15:30:00 | 2020-11-05 04:23:00 | 2020-11-05 02:28:20 |
| 1267 | L1current | $(LATCalibRoot)/TKR/LAT_BadStrips_59.xml | 2020-11-05 04:23:00 | 2021-02-03 15:41:00 | 2021-02-03 20:28:28 |
| 1271 | L1current | $(LATCalibRoot)/TKR/LAT_BadStrips_60.xml | 2021-02-03 15:41:00 | 2021-05-04 18:30:00 | 2021-05-25 07:00:51 |
| 1278 | test | $(LATCalibRoot)/TKR/LAT_BadStrips_61.xml | 2021-05-04 18:29:00 | 2021-05-04 18:30:00 | 2021-05-25 07:01:55 |
| 1279 | L1current | $(LATCalibRoot)/TKR/LAT_BadStrips_61.xml | 2021-05-04 18:30:00 | 2037-01-01 00:00:00 | 2021-05-04 21:45:51 |
+--------+-----------+------------------------------------------+---------------------+---------------------+--------------------- |
A later check of the pipeline confirmed that it is using the 1279 entry.
Further troubleshooting instructions will be added as issues come up.