inetd, xinetd¶

On *nix-like operating systems, inetd (or its successor xinetd) maintains a list of passive sockets for various services configured to run on that particular machine.

When a client attempts to connect to one of the service, inetd will start a program to handle the connection based on the configuration files.

This way, inetd will run the server programs as they are needed by spawning multiple processes to service multiple network connections.

A kdb+ server can work under inetd to provide a private server for each connection established on a designated port.

Only the kdb+ IPC protocol is supported when running with inetd or xinetd.

This is not compatible with SSL/TLS connections.

Assigning a TCP port¶

To configure a kdb+ server to work under inetd or xinetd you have to decide on the name of the service and port on which this server should run and declare it in the /etc/services configuration file.

This operation can be performed only by an administrative user (root).

/etc/services:

…
# Local services
kdbtaq          2015/tcp    # kdb server for the taq database
…

If you have multiple databases which should be served over inetd, add multiple entries in the /etc/services file and make sure you are using different ports for each service name.

Logging¶

Any logging that goes to stdout or stderr will be sent directly to the connected client by the inetd/xinetd service manager. As this isnt an IPC message, the client can generate a badmsg error when trying to decode it.

There are different options for dealing with logging:

Use the system commands \1 for stdout redirect, \2 for stderr redirect. By passing a q script on the command line to kdb+ which contain these instructions, each instance can log to a specific file.
Implement a logging framework. Note that any 3^rd party library that is loaded into kdb+ may contain code to log to stdout/stderr without using the logging framework, so this may need accounted for (see next point).
Create a shell script to run kdb+, redirecting stdout and stderr. The shell script should be used in the inetd/xinetd configuration instead of directly running the q binary.

Configuring a service manager¶

Also, as a safety measure, create one applicative group (ex: kdb) and two applicative users on your system, one (e.g. kdb) owning the q programs and the databases and another one (e.g. kdbuser) having the rights to execute and read data from the database directories.

This can be achieved by assigning the two users to the applicative group mentioned above and setting the permissions on the programs to be readable and executable by the group, and the database directories readable and executable (search) by the group: rwxr-x---.

Once this is configured, you'll need to configure inetd/xinetd to make it aware of the new service.

Inetd configuration¶

If you are running inetd, you’ll need to add the service configuration into /etc/inetd.conf (see the inedt.conf man page for more details).

/etc/inetd.conf:

…
kdbtaq   stream  tcp   nowait kdbuser  /home/kdb/q/l64/q   q /home/kdb/taq -s 4
…

Xinetd configuration¶

For xinetd, you’ll need to create a configuration file (kdbtaq for example) for the new service in the /etc/xinetd.d directory (see the xinetd.conf man page for more details).

/etc/xinetd.d/kdbtaq:

# default: on

service kdbtaq
{
    flags       = REUSE
    socket_type = stream
    wait        = no
    user        = kdbuser
    env         = QHOME=/home/kdb/q QLIC=/home/kdb/q
    server      = /home/kdb/q/l64/q
    server_args = /home/kdb/taq -s 4 -q -g 1
# use taskset to conform to license
#    server      = /bin/taskset
#    server_args = -c 0,1 /home/kdb/q/l64/q -q -g 1
#    only_from   = 127.0.0.1 localhost
#    bind        = 127.0.0.1
#    instances   = 5
#    per_source  = 2
}

Reloading configuration¶

If the service manager is already running, you can force it to reload an updated configuration file by sending the process a SIGHUP signal.

For example, the following finds the process ID of inetd, in order to send a SIGHUP signal to it.

$ ps -e|grep inetd
 3848 ?        00:00:00 xinetd
$ kill -HUP 3848