Despite the warning we introduced, many people continue to try using
prosodyctl to manage Prosody in the presence of systemctl (e.g. #1688).
Also, despite the warning, prosodyctl proceeded with the operation. This means
the commands could be invoked by accident, and cause a situation that is hard
to recover from (needing to manually track down stray processes).
This commit disables all the problematic commands by default, but this can
still be overridden using --force or via a config option.
We only perform this check when we believe Prosody has been "installed" for
system-wide use (i.e. running it from a source directory is still supported).
All commands are called with a '-h' argument, but this one doesn't have
that. Since it's meant to be machine readable, hiding it seems
marginally more sensible than implementing '-h'.
This allows user creation to happen inside the running Prosody process, which
improves a number of things - such as executing event handlers for user
creation, fixing issues and race conditions with some storage drivers, etc.
The intent is to do the same for the other prosodyctl commands, but this is
the first proof of concept for the approach.
Mostly thinking out loud about how various actions may use the shell
This enables the following sequence of commands:
prosodyctl install mod_example
prosodyctl reload mod_example
which is simpler than
prosodyctl shell module reload example
Ensures a last round of garbage collection and that finalizers are
called. Fixes things like proper closing of SQLite3 state.
There are more calls to os.exit() but most of them exit with an error or
in a case where a final GC sweep might not matter as much.
It would be nice if this was the default.
Calling util.statup.exit() everywhere may be sensible, but would be more
involved, requiring imports everywhere.
Prevents attempting to load libraries that may no longer be found and
crashing with a traceback.
Platforms like Debian where multiple Lua versions can be installed at
the same time and 'lua' pointing to one of the installed interpreters
via symlinks, there's the possibility that prosody/prosodyctl may be
invoked with Lua 5.1, which will no longer have any of the rest of
Prosody libraries available to be require(), and thus would immediately
fail with an unfriendly traceback.
Checking and aborting early with a friendlier message and reference to
more information is better.
Part of #1600
This way you don't need to set the server URL in the config to use this,
you could just ^C^V an install line from a web page that says
prosodyctl install https://modules.example.com/mod_example.src.rock
Drop the help message in this case since it'll be all messed up by being
given an URL or rock filename.
