| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
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
|
| | | |
|
| | |
| |
| |
| |
| | |
Fixes issue where it ends up creating this in $PWD, which might be
~prosody, ~you or /, depending on how it's invoked.
|
| | | |
|
| | |
| |
| |
| | |
This allows extra debug info to be provided for development purposes.
|
| |\| |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
It's not so nice to have a library that exits the entire application
from under you, so this and the error reporting belongs in util.startup.
The argparse code was originally in util.startup but moved out in
1196f1e8d178 but the error handling should have stayed.
|
| | | |
|
| | |
| |
| |
| |
| | |
This will allow using it from other places such as prosodyctl
sub-commands and plugins
|
| | |
| |
| |
| | |
prosody object
|
| |\| |
|
| | | |
|
| | | |
|
| |\| |
|
| | | |
|
