lonsql - LON TCP-MySQL-Server Daemon for handling database requests.
This script should be run as user=www. Note that a lonsql.pid file contains the pid of the parent process.
LON-CAPA is meant to distribute A LOT of educational content to A LOT of people. It is ineffective to directly rely on contents within the ext2 filesystem to be speedily scanned for on-the-fly searches of content descriptions. (Simply put, it takes a cumbersome amount of time to open, read, analyze, and close thousands of files.)
The solution is to index various data fields that are descriptive of the educational resources on a LON-CAPA server machine in a database. Descriptive data fields are referred to as ``metadata''. The question then arises as to how this metadata is handled in terms of the rest of the LON-CAPA network without burdening client and daemon processes.
The obvious solution, using lonc to send a query to a lond process, doesn't work so well in general as you can see in the following example:
lonc= loncapa client process A-lonc= a lonc process on Server A lond= loncapa daemon process
database command A-lonc --------TCP/IP----------------> B-lond
The problem emerges that A-lonc and B-lond are kept waiting for the MySQL server to ``do its stuff'', or in other words, perform the conceivably sophisticated, data-intensive, time-sucking database transaction. By tying up a lonc and lond process, this significantly cripples the capabilities of LON-CAPA servers.
The solution is to offload the work onto another process, and use lonc and lond just for requests and notifications of completed processing:
database command
A-lonc ---------TCP/IP-----------------> B-lond =====> B-lonsql <---------------------------------/ | "ok, I'll get back to you..." | | / A-lond <------------------------------- B-lonc <====== "Guess what? I have the result!"
Of course, depending on success or failure, the messages may vary, but the principle remains the same where a separate pool of children processes (lonsql's) handle the MySQL database manipulations.
Thus, lonc and lond spend effectively no time waiting on results from the database.
The number of clients each child should process.
The keys to %children are the current child process IDs
The current number of children
Inputs: None
Returns: None
Runs an sql metadata table query.
Inputs: $query, $custom, $customshow
Returns: A string containing escaped results.
Inputs: $message, the message to log
Returns: nothing
Writes $message to the logfile.
Determine if the current machine is the home server for a user. The determination is made by checking the filesystem for the users information.
Inputs: $author
Returns: 0 - this is not the authors home server, 1 - this is.
Inputs: $path, $command
Returns: unescaped string of values.
Inputs: $path, $command
Returns: unescaped string of values.
REAPER takes care of dead children.
Signal handler for SIGINT.
Signal handler for SIGHUP
Disconnects from database.