Virgo LogBook

In the majority of cases, problems with the LogBook are related to problems with pub3 - the host machine, where the LogBook application is located. However, a first analysis can be run in an attempt to recover the situation by the Software on-call. The process to follow is described here:

1. Connect to phpMyAdmin on pub3 to check the MySQL database. The URL is:
   https://pub3.ego-gw.it/EGOphpMyAdmin/
   Log-in as:  login info restricted
2. From the drop-down list on the left of the page select the database logbook. This provides a list of all of the tables in the database.
3. Click on the table tblentriesNEW (the main table in the database) in the list on the left of the page.
4. Select Operazioni from the menu at the top right of the page.
5. Select Controlla tabella at the right of the page. If the resulting Msg_text reads OK, then the table is not corrupt. Repeat steps 3 and 4 for all of the remaining tables in the database, which are listed at the left of the page.
6. In the case that the OK message is not received, click on Riparra tabella. This should resolve the problem and enable the database to run successfully again. In the case that it does not, check the the remaining tables in the same way.
7. If the database is still not working correctly, return to the phpMyAdmin homepage:
   https://pub3.ego-gw.it/EGOphpMyAdmin/
   and restart MySQL by clicking on Riavvia MySQL. This should only take a couple of seconds before re-starting.
8. If the problem persists, click on Visualizza processi in esecuzione. In the case of problems, a number of processes will be identified in this list. Try killing them one by one. If the database is still not responding at this point then it is almost certain that there is a problem with the pub3 machine and at this point you will need to contact the Computing on-call.
9. The first test that can be made by the Computing on-call is check the Apache logs in the var directory. One possibility is that the logs have filled the available space on the host and have caused a corruption of the database in the process. In this case, once the logs have been removed and sufficient space made available, before contemplating a restore of the database from the backup copy, run the myisamchk command from the command line. If this is not successful, try running the command with the option myisamchk -e. This should recover the database without the need to restore it from the backup.
10. In the case of the myisamchk command not working, consult the MySQL Repair page.
    

Detector Monitoring

Detector Monitoring displays error message stating Big Brother file is missing.

A crash of the host Big Brother host (monitor) can have knock-on effects on the Detector Monitoring application. This has only happened once in the life of the application, but it is documented for reference.

Under normal working conditions Big Brother writes data to a file bbdata.php in XML format. The file can be found in: /opt/w3/sDoc/runStatus/. However, during the VSR1 shift of the morning of the 5th of July 2007, monitor started behaving strangely and wrote a file full of corrupted data, which exceeded 3GB in size. As a result, Detector Monitoring began to display a warning message stating that a problem had been encountered with the file. The operator renamed it and replaced it with a back-up file, which enabled Detector Monitoring to work properly again, but the data in the bbdata.php file was old and no longer being updated. This is a short-term solution, which in the conditions was the most sensible thing to do, but further intervention was required to resolve the problem. Details are supplied below:

1. First and foremost, monitor and subsequently Big Brother needs to be re-started. Without this no new Big Brother data can be supplied to the Detector Monitoring application. Re-starting the machine is the responsibility of the Computing group.
2. Once monitor is back online. Check that the bbdata.php file is being updated every 5 minutes. If it is not, check the file-size. If it is 3GB in size then it will have exceeded the size available to the bb account that writes the file. Move it onto the local disk so that a new file can be written the next time Big Brother tries to write the file.
3. If there are still problems, check the current owner and group of the file. If they are not bb.cvs chmod them so that they are. Once again, this can only be done by the Computing guys using root.
4. Big Brother should now be able to successfully write data to the file and Detector Monitoring receive it without problems.