The default configuration previously contained just a listeners and
applications object. Since routes is now a principle configuration object,
and a recommended way of configurating Unit, it is now included in the
default configuration.
This change benefits new users because it explicitly introduces the three
principle configuration objects which leads more intuitively to the
documentation. Experienced users may choose to ignore or delete routes.
routes is defined as an array instead of an object because this change
is designed to assist new users, where the simpler form of routes is
easier to understand.
Improved cross-platform support by trying multiple ps(1) invocations to
obtain the unitd command line parameters. Additional error checking
detects when this process fails.
The first attempt uses `ps -wwo args=COMMAND -p` which has very broad
support and has the additional benefit of simplifying the output for
more reliable parsing of the process info. If that fails then we fall
back to simply `ps`.
The parsing of the process info has also changed. Instead of converting
'[]' into spaces we now convert them into explicit delimiters (using '^').
This is more reliable as it marks the beginning and the end of the info
we care about. Any trailing process information is now ignored (FreeBSD).
Additional error handling improves the robustness when starting unitd with
a different filename or from a relative path. In this case the control
socket and log file detection will fail when running `unitd --help`.
Additional error checking and messages are displayed when the control socket
cannot be determined. A single warning is shown when the log file cannot be
determined.
The entrypoint script now performs a default configuration when no useful
files are found in /docker-entrypoint.d/
The default configuration serves a welcome page in response to all
requests, using Markdown unless text/html is sent in the Accept header.
This provides a useful 'hello world' experience when running a Unit
container for the first time.
If unitd was started with an explicit path then unitc will use that
binary instead of the default PATH to obtain the default control socket
and log file locations.
Now unitc obtains the path to the unitd binary from information
contained in the unitd: main process. If unitd was started with an
explicit path then that path will be used to obtain the default
control socket, instead of using the unitd binary in $PATH.
Liam Crilly