Bug #1406
OnRec failing tests
100%
Description
Following power cycle, onrec01 and onrec02 machines are failing tests, though each installation is failing on different tests... test log attached.
Files
Updated by Rajaram, Durga over 9 years ago
- File onrec01-unit_tests_fixcabling.log onrec01-unit_tests_fixcabling.log added
- File onrec01-application_tests_fixcabling.log onrec01-application_tests_fixcabling.log added
- File onrec02-unit_test_fixcabling.log onrec02-unit_test_fixcabling.log added
- File onrec02-application_tests_fixcabling.log onrec02-application_tests_fixcabling.log added
It turned out to be an issue with the DAQ cabling maps on onrec01/02 which affected the unpacking and hence the failure in the md5 check on the unpacked data.
Details: on the last day of running during the EMR run, the Ckov ADC module was put back into a slot different from the original one. DAQChannelMap.txt was then modified to get the DAQ to recognize the board. The different fADC id/geo/channel in the map caused the unpacked data to have a different checksum.
I have reverted back to the 'original' map on onrec01 & 02. The modified maps are in files/cabling/DAQChannelMap_2013Oct27.txt
Re-ran the tests -- unit tests pass on both onrec01 and 02
Application tests -- failed on onrec01 but passed on onrec02 -- it looks like RabbitMQ is not running on onrec01 -- and I don't have the root password to (re)start it.
Updated by Rogers, Chris over 9 years ago
I restarted rabbitmq-server, tried rerunning the application tests on onrec01 and got a fail in the Celery stuff and a skip in some of the other online stuff. Perhaps this is just a false negative, so I will stupidly just try rerunning the tests and see what happens.
Durga, following the reversion of the map, will this mean that the reconstruction will now fail to reconstruct Ckov? Did the ChannelMap get put back to normal since the last data run? Yordan may be able to comment...
Updated by Rajaram, Durga over 9 years ago
Unless the module got put back into its original place, the Ckov will fail to reconstruct with the reverted map. I don't see any elog entry indicating that it happened.
Updated by Karadzhov, Yordan over 9 years ago
The place of the module doesn't make any difference. The Geo number of the board, which is different for this particular run is set by the DATE data base. I have no idea who made this change in the data base and respectively, why this change is not documented in the logbook. However, the content of the DATE DB is now back to its original state. This means that a special version of the cabling will be needed only if you want to analyze the CKOV runs taken at the very end of the EMR data taking period.
Updated by Rogers, Chris over 9 years ago
- Status changed from Open to Closed
- % Done changed from 0 to 100
In that case, I think that MAUS as installed should reconstruct okay - so I will not change anything and close the issue.
Durga, if you want to give me a ring Re: onrec machine passwords, I can tell you what they are.
Updated by Rajaram, Durga over 9 years ago
- Target version changed from Future MAUS release to MAUS-v0.8.1