The process of creating the kloned executable, by embedding the web content into the server process, is documented in the klone(1) manual page.
kloned depends on sup://etc/kloned.conf for the configuration of its instances (clones). Additional configuration can be supplied via an external file (the -f command line flag): see kloned.conf(5) for details on available configuration parameters and their respective values.
KLone is a product targeted for embedded systems, especially those with limited or no disk resources; as such it tries to reduce logging activity to a minumum (at its best, zero logging).
Diagnostics issued by kloned are passed to the syslogd(8), subsystem with facility LOG_LOCAL0 and priority LOG_DEBUG and can be routed to a configurable file (see syslog.conf(5) for details).
The number and nature of diagnostics available depends on the debug level defined at compile-time. If you are having problems, compile the KLone application with NDEBUG unset, configure the syslog daemon appropriately, run your application and peruse the log files. Most messages are reasonably self-explanatory. At this stage your best bet is still to grep the source code and inspect the conditions that gave rise to the diagnostics you are seeing.
kloned is a service/daemon, as such it will bail out with an EXIT_SUCCESS exit code only if explicitly requested to terminate (i.e. SIGTERM or SIGINT), otherwise it will exit with EXIT_FAILURE.
The following environment variables affect the execution of kloned:
To shut down a user's kloned process it is recommended that SIGKILL not be used, except as a last resort. The safe way to terminate a kloned is to send it a SIGTERM or SIGINT signal and wait for it to die on its own.
Sure there are some. If you find one, please email it to <email@example.com>.