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.
Directory Structure
/RiApps/
guruServer/
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)
/RiGuru/
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/
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.
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.)
rev/
RiGuruArchive/ - "Hot Copy" in case file in repository detected as corrupt (digital signature verification fails) - can be disabled with the "NoGuruArchive=true" attribute added to the RiSystem object with ri.sys.Owner that matches the Guru ID of the server. (restart required)
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].
Table 1: Guru Server Startup Commands
Modify the GuruServerStart launch script by prepending the relevant "-command <value>" after startApp.cmd line. Alternatively, flags may be added without the "Ri" in front and "=true" after the flag name between the ":INFO" and ":CHECKSUM" lines to the RiSystem object matching that Guru ID. Command arguments and flags can be included in any order. Some features require a specific version of Guru Server or later.
 Command Arguments (Guru Version) | RiSystem :INFO Section | Description |
-RiNoBackup -RiNoUpdate -RiNoClone -RiDebug -RiLogSM -RiRootGuru -RiNoExpired -RiBox -RiUpdateGuru <value> -RiBackupGuru <value> -RiMaxWait <value> -RiDeleteBadHash -RiRecoverBadAttrHash -RiNoAutostartDbManager -RiAutolaunch (v74.32) -RiNoGuruArchive (v74.36) | NoBackup=true NoUpdate=true NoClone=true Debug=true LogSM=true RootGuru=true NoExpired=true Box=true UpdateGuru=<value> BackupGuru=<value> MaxWait=<value> DeleteBadHash=true RecoverBadAttrHash=true NoAutostartDbManager=true Autolaunch=true NoGuruArchive=true | do not look for backup guru do not look for update guru do not look for clone guru turn on debug messages log system messages Same as no backup no update Does not delete expired object Cassini system software in VirtualBox container, only for Linux and Windows host Sets the IP address for the update guru, first try Sets the IP address for the backup guru, first try TCP socket timeout, sets the max wait time in milliseconds for the Guru communication default of 10000 (10 seconds), increase this number for high latency connections Cleans up bad hash objects Guru will try to recover bad attribute hash Does NOT launch DbManager at startup. minimum Guru Agent launch parameter, defaults to 600 (10 minutes) v74.32 Disables RiGuruArchive creation (local redundant copy to avoid OS write errors) |