Deploying a Common Lisp server application in production requires that it runs as a daemon.

A Unix init system like Upstart or systemd can be used to ensure that the service is always running. In this case the application can daemonize itself or it can run in the foreground and let the init system take care of daemonization.

It is usually easier to create an init script for a self-daemonizing application but then the source code gets more complicated.

When the application runs in the foreground the init script is slightly more tricky but the application is easier to debug.


The procedure to daemonize an application is well documented but most of these documentation is focused on C. To implement the complete procedure in Common Lisp can become a mission in itself because it involves forking and opening and closing standard IO stream at the right times.

The daemon package implements all the necessary steps and provides a trivial API for daemonizing a program.

Though daemon is easy to use, all the forking makes it difficult to get backtraces when something goes wrong. The application then appears to be hanging while it is actually waiting in the debugger for input but the debugger can’t be used because standard IO is closed.

When a service daemonizes itself it is advisable to devise some method to interact with the application while it is waiting in the debugger. One of the swank libraries could be useful.

Run in foreground

Foreground applications can be used as-is for a service but it can not be used as the main application instantiated by the init system.

During the daemonizing process the init system closes all the standard IO streams. This causes the REPL to exit and the application to end.

GNU Screen can be used to keep the standard IO open for a daemonized service. However, when an error occurs one is in much the same situation as with a self-daemonizing application. The application appears to hang because it is waiting in the debugger but the debugger can’t easily be reached.

Screen has options to log standard IO to a file. Debugging then consists of killing the service and working through the logged backtrace. This is not ideal but it has the advantage of not introducing any code complexity in order to make a daemon.

Like in the self-daemonizing case, a swank library can be used to get live debugging back.

Comparing the options

Self-daemonizing Foreground
Daemonizing responsibility Common Lisp code Unix init system
Tool daemon library GNU Screen
Init script complexity Less complex More complex
Code complexity Increased complexity Same complexity as normal program
Debugging options Embedded swank server Logged data or embbeded swank server