All relevant AMS support routines are located in /usr/etc/ooss. You execute programs from this directory. Some of these programs will also execute programs from sub-directories (e.g., amscur).
How do I start the SLAC AMS?
To start the AMS use the StartAMS script. This script allows you to specify the port that is to be used, along with the number of threads to service client requests. Detailed documentation can be found in the AMS oofs/ooss Configuration Guide.
How do I stop the SLAC AMS?
To stop the AMS use the StopAMS script. If you run multiple AMS servers, this script will stop all of them. Detailed documentation can be found in the AMS oofs/ooss Configuration Guide. Alternatively, you can use the oostopams provided by Objectivity to stop selected AMS servers. However, this will not work if the AMS is in a catatonic state.
Where are log files kept?
Log files are stored in two places: /var/adm/ooss/logs and in /var/adm/messages in Solaris, and /var/log/messages in Linux. Critical messages are always placed in the system log file, /var/adm/messages. Operational messages are always placed in /var/adm/ooss/logs. Log file names placed in this directory are determined by the StartAMS.cf configuration file.
Where are core files placed?
Core files from AMS crashes are always stored in /usr/spool/objy. Only one core file can be maintained at any one time (that is, new crashes always replace the existing core file). We recommend that you develop procedures to rename core files as they are generated so as not to loose valuable debugging information.
How do I know the AMS is running?
The system top command allows you to determine whether the AMS is using CPU time, as well as its memory utilization. When you run top, you may see more than one AMS process.
In Solaris, two AMS processes are created when you enable the Mass Storage Interface. Otherwise, there is only one AMS process. If you run multiple AMS per host, you will see more AMS processes, consistent with the number you started.
In Linux, one AMS process is started for each thread (even more if the Mass Storage Interface is enabled). This may be confusing. The master AMS is always the one with the lowest process id that has no AMS process as its parent.
If the AMS is not being used, it is likely that the top command will not show them. In this case, use the ps command. To pick out the AMS processes issue:
ps -ef | grep ooams
This will display all AMS processes.
You can always use the oocheckams command provided by Objectivity to see if an AMS is running. However, there are conditions in which the AMS will respond to oocheckams but will not be able to process user requests. There is no direct way of discovering this situation. Should it occur, you obtain a core dump by sending the AMS an un-handled signal (e.g., kill -ABRT pid), or using gcore command.
How can I debug AMS?
In general, you cannot debug AMS unless you are completely familiar with its internals. Should you see a core dump not associated with a hardware failure (check /var/adm/messages for possible hardware problems), allow one of the BaBar database developers to examine it for obvious problems. If none can be found, you may be asked to run a special version of AMS that includes debugging information, to help solve the problem.
BaBar Public Site | SLAC | News | Links | Who's Who | Contact Us
Page Owner: Jacek Becla
Last Update: June 13, 2002