registry: add hidden experimental status file argument

[VDanielEdwards]

Subject

This change adds a hidden command line argument --x-status-file to the sil-kit-registry executable. It expects a path that can be opened for file creation, truncation, and writing.

The registry will rewrite this files content to starting at an early point in the startup procedure.

After the registry has started listening for incoming connection, the files content will be rewritten to running.

When the registry is shutting down 'normally' (e.g., CTRL-C, handled signals, or a handled exception) the files content will be rewritten to stopped. The file is also deleted afterwards. The rewrite ensures that even if the file cannot be deleted for some reason, it will not contain running anymore.

Such a status file is very useful for implementing a health check for orchestrated container setups, e.g., using docker-compose. It allows the user to ensure that participant containers are only started after the registry is up.

Why Hidden & Experimental

The argument is useful in this state (for the example given above), but it may not be enough. We might think about either adding a separate PID-file argument, or integrate that functionality with this argument.

Personally I believe that this needs to be used in our own workflows until it's clear that it can be 'released'.

Developer checklist (address before review)

• Changelog.md updated
• Prepared update for depending repositories
• Documentation updated (public API changes only)
• API docstrings updated (public API changes only)
• Rebase → commit history clean
• Squash and merge → proper PR title

[VDanielEdwards]

The actually used states are starting, running, and stopped.

[snps-kratz]

In the case of an abnormal shutdown, i.e. SIGSEGV, SIGKILL, SIGABRT the file might become stale, which could be a problem for a "healthcheck"-feature. As you already noted, adding PID content could allow the consumer to check against this scenario.

[VDanielEdwards]

In the case of an abnormal shutdown, i.e. SIGSEGV, SIGKILL, SIGABRT the file might become stale, which could be a problem for a "healthcheck"-feature. As you already noted, adding PID content could allow the consumer to check against this scenario.

I fully agree. In case of a crash, or deliberate 'sudden' termination of the registry, this will lead to 'invalid' health-checks.

I think in the long term, a (local domain) control socket may be the best solution. This would avoid the problems with PID files (PIDs can be reused) and allow for much more flexibility.