Idea is to enable easily retrieving of secret values from files outside
of the config, e.g. via the method used by systemd credentials.
CREDENTIALS_DIRECTORY is expected to be set by the process manager
invoking Prosody, so being unset and unavailable from prosodyctl is
going to be normal and a warning is reported in that case. Care will
have to be taken to make it clear that prosodyctl check will not work
with such values. An error is thrown if the directory is unavailable
when running under Prosody.
This lets Prosody report its lifecycle status to systemd, so it knows
when Prosody has completed its startup, when it's reloading and shutting
down.
Both Type=notify and Type=notify-reload is supported
Example systemd .service configuration snippet:
[Service]
Type=notify
prosody.shutdown() relies on prosody.main_thread, which has not been set
yet at this point.
Doing a clean shutdown might actually be harmful in case it tears down
things set up by the conflicting Prosody, such as the very pidfile we
were looking at.
Thanks again SigmaTel71 for noticing
Ensures that startup.detect_platform() runs so know whether to use the
POSIX method of checking the current user or something else. Also after
reading the config so we know whether the root override setting is set.
This allows greater control over the order of events.
Notably, the internal ordering between daemonization, initialization of
libunbound and setup of signal handling is sensitive.
libunbound starts a separate thread for processing DNS requests.
If this thread is started before signal handling has been set up, it
will not inherit the signal handlers and instead behave as it would have
before signal handlers were set up, i.e. cause the whole process to
immediately exit.
libunbound is usually initialized on the first DNS request, usually
triggered by an outgoing s2s connection attempt.
If daemonization happens before signals have been set up, signals may
not be processed at all.
Broke signal handling again, such that an early s2s connection results
in libunbound catching signals and getting Prosody killed on e.g. SIGHUP
This returns to the situation where prosody --daemonize does not respond
to signals.
When libunbound is initialized, it spawns a thread to work in.
In case a module initializes libunbound, e.g. by triggering a s2s
connection, Prosody would not handle signals, instead immediately quit
on e.g. the reload (SIGHUP) signal. Likely because the libunbound thread
would not have inherited the signal mask from the main Prosody thread.
Thanks Menel, riau and franck-x for reporting and help narrowing down
To avoid a race where server-started fires before the promise function body is
run (on next tick), I moved server-started to fire on the next tick, which
seems sensible anyway.
Errors are logged, I'm not sure if we ought to be doing something more here.
I'm sure we'll find out.
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.
Observed problem: When shutting down prosody would immediately exit
after waiting for s2s connections to close, skipping the last cleanup
events and reporting the exit reason and code.
This happens because prosody.main_thread is in a waiting state and
queuing startup.shutdown is dispatched trough the main loop via
nexttick, but since the main loop was no longer running at that point it
proceeded to the end of the prosody script and exited there.
Original motivation was tiresome warnings about Lua 5.4 not being
supported yet.
Can still be handy to tweak log level, e.g. to prevent logging to
interfere with command output.
The 'prosody' global is not global this early so there was no way to
override the process type field or argument parsing settings from
outside, e.g. from the migrator.
Having it relative to current working directory is problematic since
this depends on how Prosody was started and changes to the data
directory during startup (but after this point).
Since this runs before dropping root, the directory ends up being owned
by root, resulting in luarocks failing to install anything, since by
then it would be running as the prosody user.
luarocks creates this directory if needed, so creating it during startup
is not necessary.
One potential issue is if the directory is somewhere where Prosody can't
write, but then you will simply have to create it yourself with the
appropriate permissions.
