Overview

ServerKit modules are shared objects that are dynamically loaded at runtime by the server program.

When the server program opens a module using dlopen(), it attempts to find a specific symbol named "ServerModule". All ServerKit modules must contain the ServerModule symbol, or they will not load.

After successully opening a module, first ServerModule.build_ver_major is compared against the major version number of the active ServerKit runtime. If the major version differs module loading is aborted. If major versions are similar, ServerModule.build_ver_minor is compared against the minor version of the active ServerKit runtime as well. If the minor version is found to be newer than the runtime minor version a warning will be printed but loading will continue. ServerModule.build_ver_micro differences are ignored.

If all version checks have been passed without aborting, the construct method of the module is invoked. If the construct method returns 0 further loading of the module is aborted and an error printed.

After the above steps have progressed for all configured modules in a ServerKit personality, the prestart stage of startup is entered. In this stage the prestart method of all the loaded modules is invoked serially. If any prestart method returns 0 the process is aborted with an error, it is important to note that the prestart stage is entered before any potentially configured user switching ocurrs. If your modules require root for some early initialization steps, such as opening a sensitive file or binding to a low port number, prestart is where you should probably do it.

Once the prestart stage completes, any configured user and group switching is performed then the operator method of every loaded module is invoked serially but rather than being simply called from the server process context, the operator method is actually invoked as an independent POSIX thread via pthread_create().