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:
- The location of the configuration file. Defaults to
agraph.cfgin the executable's directory, or, failing that,
- Specify where the server log files are written. Overrides the
- Start the server in debug mode, which means logging will be more verbose.
- Set an explicit log-level (debug, info, warn, or error), or specify log-levels per category, for example:
- Write a log of all HTTP traffic to the file specified.
- Determines where the process id of the server is written. Override the
- If started as root, run AllegroGraph as the specified user. Overrides the
- Print information about these arguments.
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.
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.
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.
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.