| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
| |
Prevents creation of log files owned by the root user which could be
inaccessible once started correctly.
|
| |
|
|
| |
root (thanks SigmaTel71)
|
| |
|
|
|
|
|
|
| |
SigmaTel71)
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.
|
| |
|
|
|
|
| |
signalfds stop working with epoll after forking
hooking signals later should not affect anything
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
for convenience.
|
| |
|
|
| |
Maybe we need some sort of lint for this?
|
| | |
|
| | |
|
| |
|
|
|
| |
Useful to have this info available when juggling metrics, e.g. to
see if things changed between versions.
|
| |
|
|
| |
Module was removed in 0.8.0 in c52b06de9b27
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
Mostly in order to avoid triggering the XML syntax highlighting in the
console logger.
|
| | |
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | |
| |
| |
| |
| | |
Mostly to ensure it is available during tests, as util.startup is not
invoked there
|
| |/
|
|
| |
Code deduplication
|
| |
|
|
|
| |
Fixes error in mod_authz_internal due to import() being unavailable as
it was only loaded in Prosody proper
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
(fixes #1722)
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
|
| |
prosodyctl -h showing an error was not very helpful, especially since
prosodyctl shows its help for any unknown (or none) command.
|
| |
|
|
|
| |
Seems more suitable than asking if prosodyctl was meant to be used, or
going ahead and starting.
|
| |
|
|
|
|
| |
This field is empty for reasons when invoked by prosody-migrator, which
threw an error:
> bad argument #1 to 'open' (string expected, got nil)
|
| |
|
|
| |
#1692)
|
| |
|
|
|
|
|
| |
prosodyctl
Makes it clearer that prosody does not take -v atm, as well as how
prosodyctl does not take the demonization flags.
|
| |
|
|
| |
More convenient than the environment variable.
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
Testing has demonstrated that the default GC parameters are not
sufficient to prevent runaway memory growth when running under Lua 5.2
and Lua 5.3.
Setting the GC speed to 500 was tested on Lua versions 5.1->5.4 and did
not display unbounded memory growth.
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
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.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| | |
Improves usability of the console when digging around the internals.
No specific rationale for the function<file:line>(args) format, it
looked best of the variants I tried.
|
| | |
| |
| |
| | |
debug.getinfo(f) collects more info than what is needed here.
|
| | |
| |
| |
| |
| |
| | |
Makes it easier for other parts of the code to use this for things, such
as determining whether a certain module is from this path or from
elsewhere.
|
| | |
| |
| |
| | |
As is normal when running from source
|
| | | |
|
