Procedure: What to do when burntool does not start

Case 1: One VALID image was not copied from the summit

Do not use this procedure if the image is NOT valid.

• Step 1: Check in the relevant log file (that is: ~ipp/summitcopy/pantasks_stdout.log) what the failure was. You should see something like:

  […]
  Starting script /home/panstarrs/ipp/psconfigipp-20100823.lin64/bin/summit_copy.pl on ipp047
  Running --uri http://conductor.ifa.hawaii.edu/ds/gpc1/o5440g0622o/o5440g0622o45.fits --filename \
     neb://ipp047.0/gpc1/20100901/o5440g0622o/o5440g0622o.ota45.fits --compress --bytes 49429440 --nebulous --md5 58b0a9754a3b402e8c64d6b2ff30b533 --timeout 600 --copies 2
  downloading file to /tmp/o5440g0622o.ota45.fits.LKzXHdnA.tmp
  * stderr *
  uri: http://conductor.ifa.hawaii.edu/ds/gpc1/o5440g0622o/o5440g0622o45.fits?compress - expected md5: \
     58b0a9754a3b402e8c64d6b2ff30b533 got: 55b13b25c58c1420ab4769d8ec6105b0 at /home/panstarrs/ipp/psconfig/ipp-20100823.lin64 \
     /bin/dsget line 142
  checksum failed at /home/panstarrs/ipp/psconfig/ipp-20100823.lin64/bin/dsget line 154.
  Unable to perform dsget: 9 at /home/panstarrs/ipp/psconfigipp-20100823.lin64/bin/summit_copy.pl line 233.
  
  failure for: summit_copy.pl —uri http://conductor.ifa.hawaii.edu/ds/gpc1/o5440g0622o/o5440g0622o45.fits \
    —filename neb://ipp047.0/gpc1/20100901/o5440g0622o/o5440g0622o.ota45.fits —exp_name o5440g0622o —inst \
    gpc1 —telescope ps1 —class chip —class_id ota45 —bytes 49429440 —md5 58b0a9754a3b402e8c64d6b2ff30b533 \
    —dbname gpc1 —timeout 600 —verbose —copies 2 —compress —nebulous
  job exit status: 9
  job host: ipp047
  job dtime: 24.381314
  job exit date: Wed Sep 1 08:35:15 2010
  

You should get the faulty exposure, its class_id, and the reason why it was not copied, for instance:

• o5440g0622o
• ota45
• expected md5: [...] got: [...]

• Step 2: Ask the camera group if the image is valid. Send an e-mail to ps-camera_at_ifa.hawaii.edu providing them those three informations. If you know how to do it, you can download the file (use dsget?) and look at it (use ds9?).

• Step 3: Stop the summitcopy pantasks server:

ipp@ipp004>>> cat ~ipp/summitcopy/ptolemy.rc | grep PANTASKS_SERVER
PANTASKS_SERVER ipp051
ipp@ipp004>>> ssh ipp@ipp051
ipp@ipp051>>> cd summitcopy
ipp@ipp051>>> pantasks_client
  pantasks: shutdown now
  (I then got the following message: 'exit status of 1 / message status of -3', I hope it's fine...)
  pantasks: exit

• Step 4: Revert

The status of the faulty entry can be checked in the gpc1 database.

ipp@ipp051>>> mysql -h ippdb01 -u ipp -pipp gpc1
mysql> select * from pzDownloadImfile where exp_name='o5440g0622o' and class_id='ota45';
+-------------+--------+----------—+-------+----------+------------------------------------------------------------------------+-------+-------+----------+-------+--------+
| exp_name    | camera | telescope | class | class_id | uri                                                                    | fault | epoch | hostname | bytes | md5sum |
+-------------+--------+----------—+-------+----------+------------------------------------------------------------------------+-------+-------+----------+-------+--------+
| o5440g0622o | gpc1   | ps1       | chip  | ota45    | http://conductor.ifa.hawaii.edu/ds/gpc1/o5440g0622o/o5440g0622o45.fits | 9     | [...] | NULL     | 0     | NULL   |
+-------------+--------+----------—+-------+----------+------------------------------------------------------------------------+-------+-------+----------+-------+--------+

The faulty entry can then be deleted:

mysql> delete from pzDownloadImfile where exp_name='o5440g0622o' and class_id='ota45';
Query OK, 1 row affected (0.01 sec)
mysql> quit

• Step 5: Copy the file from the summit and register it into the gpc1 database

The following command is the one that can be found in the log file without the md5 argument.

ipp@ipp051>>> 
summit_copy.pl uri http://conductor.ifa.hawaii.edu/ds/gpc1/o5440g0622o/o5440g0622o45.fits —filename neb:ipp047.0/gpc1/20100901/o5440g0622o/o5440g0622o.ota45.fits —exp_name o5440g0622o —inst gpc1 —telescope ps1 —class chip —class_id ota45 —bytes 49429440 —dbname gpc1 —timeout 600 —verbose —copies 2 —compress —nebulous

• Step 6: Check entry status in the database

Check that the entry is now valid in gpc1 database:

mysql -h ippdb01 -u ipp -pipp gpc1
mysql> select * from pzDownloadImfile where exp_name='o5440g0622o' and class_id='ota45';
+-------------+--------+----------—+-------+----------+---------------------------------------------------------------+-------+-------+----------+----------+--------+
| exp_name    | camera | telescope | class | class_id | uri                                                           | fault | epoch | hostname | bytes    | md5sum |
+-------------+--------+----------—+-------+----------+---------------------------------------------------------------+-------+-------+----------+----------+--------+
| o5440g0622o | gpc1   | ps1       | chip  | ota45    | neb:ipp047.0/gpc1/20100901/o5440g0622o/o5440g0622o.ota45.fits | 0     | [...] | ipp051   | 22420800 | [...]  |
+-------------+--------+----------—+-------+----------+---------------------------------------------------------------+-------+-------+----------+----------+--------+

• Step 7: Restart the summycopy pantadks server

(see the paragraph ​Processing # Starting a single server)

• Step 8: After some time, the activities should resume to normal (i.e. QUEUEBURNING status)

Notes

For Step 4 (and later?) pztool can be used to revert. If you know how to do it, write it down. If you don't have time to write it, tell Serge so that he can write it.

pztool -revertcopied?

Case 2: One INVALID image was not copied from the summit

If you know how to do it, write it down. If you don't have time to write it, tell Serge so that he can write it.