Guru Server is a object store Cassini relies on for normal operation. It performs online update and backup functionality and vital for typical production activities including datalog copy and DUT project release details. A single server can be configured as the update/backup/datalog target for Cassini System Controllers and Cassini Virtual Workstations. Guru Servers can be connected via Guru Agent for timed syncronization or work as a clone pair for high availabiltiy (HA) with failover and redundancy capabilities.
The GuruServer application is the same codebase and version numbers as the version running on the tester.
The Guru Server typically runs on a virutal Linux server with a X based desktop environment (RI recommend xUbuntu). A dedicated "guru" user is created, the program is installed in the "/home/guru/RiApps" directory (aka "~/RiApps/" folder) and data stored in "~/RiGuru/" folder.
The process is launched by a "startApp.sh" that is added to the GUI's desktop (XFce, KDE or Gnome) standard auto-start location. Note: A GUI is required, Guru Server can not launch "headless".
When Guru starts, the program files are always copied fresh from the "guruServer.zip" container and then launched. This step assures consistency and prevents any random disk read or write errors related to aging from interfering with the program launch. If the script fails to properly unpack the program from the guruServer.zip file, the script launches the version that remains on the disk.
Guru checks /mnt/floppy which should be linked to a .vdf file in the home directory, storing the GuruKey (GuruID and private encryption keys). (See Installation Instructions for details)
Guru builds a database in memory based on a collection of attribute (.gab) and object (.gob) files in the ~/RiGuru/repository directory.
guruServer.zip (archive that is unpacked before each run), replace this file to upgrade/downgrade
startApp.cmd (launch command, a Desktop launch script should be used with default operating parameters)
GuruKey/SystemID, <GuruID>.rsa (the auto generated guru ID and private encryption key used in case the /media/floppy mount containing the actual GuruKey is not accessible via loop device)
local.bak (backup made at startup of "local" attributes)
local.jnl ("ri.local" guru attributes that are only accessible to clients connecting via the local tcp port 50010) Stores dynamic metadata that is lost when this file is removed.
main.bak (backup made at startup of "main" guru attributes)
main.jnl (all guru attributes except "ri.local" - created at startup with the contents of every .gab) Improves startup time, SHOULD be removed when files are removed from the repository.
###/ (three digit numbered folders base on a hash of the CID for random file distribution to not stress host os filesystem)
<CID>.GAB - Guru Attribute File: All the guru attributes associated with the CreationID (aka "CID")
<CID>.GOB - Guru Object File: The contents of the guru object (datalog STDF, ATDF, RITdb, .cff (common file format, ascii based file for all Testplans, CalData, etc.)
RiGuruArchive/ - "Hot Copy" in case file in repository detected as corrupt (digital signature verification fails)
OutOfSyncGuruTime/ - Debug directory containing contains guru objects who's CID does not align with the ri.sys.CreationDate). This can happen if the local clock is dramatically off in the past/future. Guru automatically syncs it's internal clock with the "update" Guru Server connection. If that connection is intermittant (or the user is away from the network and enablels VPN) then the CID can change but the CreationDate is off.
To prevent Guru from restarting, kill the "startApp.sh" process. Normally the Guru Server application automatically restarts when System > Shutdown button is pressed. This prevents the service from being inadvertently shutdown.
If the guru server is unresponsive or needs to be stopped for any reason, you can open a command window as root and issue "ps -A | grep es" command to see the process ID (PID) of the guru server. Force the process to stop with "kill -p <PID>" for each process identified. If the problem persists after a restart, copy "guruServer.zip" from a know working backup. If the problem continues, try restarting the host OS. Some OS upgrades may remove or relocate critical system files and may require a symlink ("ln -s /path/to/file") to be created to maintain backward compatibility.
If a walkback occurs, select "SAVE" from the dialog box and send the error log (~/RiApps/vterror.log) to [email protected]