I've been trying out the example init script for Canto, and I think it's a bit peculiar how the actual init script file (link) doesn't do anything except run another script file that does all the work (link).

The only reasons I can see for this approach are:

1. To allow the script to be run as root, although presumably if the script was run through init.d then the script would be run as root anyway, or at least with sufficient priveleges; and

2. To fix additional arguments, like the port number for Canto.

I investigated how other init scripts solve the problem of additional configuration, and it seems the conventional approach is to add a file in /etc/default/ containing variables that are then sourced into the main script file. Personally, I'd prefer to have only one init script which sets default values, and keep the configuration overrides in a separate file.

The existing init scripts I've looked at have competing approaches to how they check the validity of their configuration files, but they're broadly equivalent. Some examples are shown below:

cron

-r: True if file exists and is readable.

[ -r /etc/default/cron ] && . /etc/default/cron

D-Bus

-e: True if file exists.

if [ -e /etc/default/dbus ]; then
    . /etc/default/dbus
fi

Docker

-f: True if file exists and is a regular file.

if [ -f /etc/default/$BASE ]; then
    . /etc/default/$BASE
fi

Based on the init script for Docker, it seems any variables sourced from the file in /etc/default/ will override the variables in the main script, so the script can declare default values and then override them if a default file exists: there's no need to put the default declarations in an else block. The variables are left commented out in the configuration file, and presumably it's up to the user not to override the default values with empty values by accident.

These are the following variables that I think should be configurable:

• WORKERS: maximum number of workers for Server::Starter; it would be useful to allow this to be lowered for development setups that could be more memory-constrained.
• port: the port number for connections to Canto.
• CANTO_SPACE: the directory for Canto's source files; this is mainly important for my development setup, since that doesn't use the same directory as our servers.
• PID_PATH: this probably matters less, since I think it only applies to the Docker container, but it might be useful to someone if it were configurable.

Note that systemd seems to use a different approach to overriding configuration (see docs), so it's worth being aware of that in case any Canto user decides to migrate to systemd in future. We might want to document the configuration override process for both service managers (SysV style and systemd style).

@kimrutherford are you happy with this approach? Are there any compelling reasons to stay with the current approach? I'm happy to take care of making the changes, testing them, and updating the documentation. I realise that FlyCanto might already be using the existing system, so I'll have to take care that any changes don't inconvenience them.