Table of Contents

Running the Server

HTTP Access

Processes

Reloading the Configuration File

Log Rolling

Advanced: Debugging

This document goes into a bit more depth about the server. When you are simply interested in getting a server running, the installation document should suffice.

AllegroGraph runs as a daemon process, which listens for HTTP connections on one or more ports. It is, as with all daemon processes, adviseable to run the server under a user with as few privilleges as possible.

Running the Server

The daemon binary, agraph, can be invoked directly to start the daemon. It accepts the following command-line arguments:

--config file
The location of the configuration file. Defaults to agraph.cfg in the executable's directory, or, failing that, /etc/agraph/agraph.cfg.
--log-dir directory
Specify where the server log files are written. Overrides the LogDir directive.
--debug
Start the server in debug mode, which means logging will be more verbose.
--log-level level
Set an explicit log-level (debug, info, warn, or error), or specify log-levels per category, for example: debug,daemon:info,storage:warn.
--http-trace file
Write a log of all HTTP traffic to the file specified.
--pid-file file
Determines where the process id of the server is written. Override the PidFile directive.
--run-as user
If started as root, run AllegroGraph as the specified user. Overrides the RunAs directive.
--help
Print information about these arguments.

HTTP Access

The quickest way to check whether a server is running is to just visit its port with a web browser. If the server is running on your local machine, on the default port, http://localhost:10035/ will bring up WebView, the server GUI. If you log in using the superuser account you either entered in your configuration file, or created with the configuration helper script, WebView allows you to query and modify your triple-stores, and to configure user access.

On this same port, the HTTP procotol is exposed, which is used by the various client libraries (and in fact, also by WebView itself). If you configured SSL access, these same services are available as https:// URLs on the port you choose for SSL.

Processes

During normal operation, the daemon will spawn extra processes. When multiple triple-stores are open, or a lot of dedicated sessions are being requested by clients, the amount of processes can become quite large. To find which of them is the main daemon, either use the PID file that the daemon wrote, or look at the process names. For example:

$ ps aux | grep AG  
agraph 17242 0.1 6.4 4757000 130856 Ss Feb25 1:51 AG Service Daemon      
agraph 20128 0.0 3.8 392372  78024  S  Feb25 0:00 AG Hub                 
agraph 20173 0.0 4.1 394948  83164  S  Feb25 0:04 AG backend 1           
agraph 22928 5.6 8.3 4712520 169584 S  11:47 0:00 AG store1 instance  
agraph 22929 2.5 3.8 392372  77912  S  11:47 0:00 AG store1 SHM Server  
agraph 22930 0.6 3.8 4686916 77968  S  11:47 0:00 AG store1 Checkpointer  
agraph 22931 0.3 3.8 4686916 77972  S  11:47 0:00 AG store1 Merger  
agraph 22932 0.3 3.8 4686916 78004  S  11:47 0:00 AG store1 FTI Merger  
agraph 22933 0.3 3.8 4686916 77968  S  11:47 0:00 AG store1 UPI Table 

The process titles reflect the roles of the processes. Here we see the daemon itself, the "hub" (a helper process that manages inter-process communication), a single HTTP worker process (backend 1), and six processes related to the store named store1, which was open at the time.

To shut down the daemon, send the main process (17242 in this case) a TERM signal.

Reloading the Configuration File

There are two ways to tell the server to reload its configuration file. The first is to send a USR1 signal to the daemon process, and the second is to make an HTTP POST request to the /reconfigure URL on whatever port the server is running.

Log Rolling

Sending a HUP signal to the daemon process will cause all server processes to close and re-open their log file. Thus, clearing the log is done by deleting the logfile, and then sending this signal. Rolling is done by moving the log to a different filename (say, agraph.1.log), and then sending this signal.

Advanced: Debugging

When things go wrong, the AllegroGraph server provides the possiblity of inspecting the process stacks of its processes. The easiest way to do this is to log into WebView with a superuser account, and click the "Processes" link. This will list the server's processes, and allow you to list backtraces for each of them. These backtraces will be rather hard to read for outsiders, but when diagnosing a server error, our staff will often ask for them.

When the server is in such a broken state that fetching the stack traces over WebView no longer works, sending a USR2 signal to a process might still cause it to output its stack trace to the log file.

Another option you have when inspecting the processes in WebView is to open a telnet server in them. This will give you a port number, on which you can start a telnet session to talk to the process using a Common Lisp prompt. Be aware that such telnet ports are in no way secured. Don't leave them open on machines open to untrusted parties.