| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|\| |
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This enables accepting admin stream socket (UNIX) connections trough the
same procedures as any other (TCP) socket, which avoids problems caused
by using the wrapclient API, which ends up discarding early data due to
only expecting early connection failure.
Fixes #1867
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This change has various technical and social benefits. If ownership of a MUC
is really needed, it can be gained using the 'Set affiliation' ad-hoc command
or prosodyctl shell.
Example client incompatibility with the old behaviour:
- https://github.com/monal-im/Monal/issues/1085
|
| |
| |
| |
| | |
Based on mod_muc_restrict_pm in prosody-modules d82c0383106a
|
|\| |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Previously, prosodyctl only waits for the pidfile to appear, which does
not necessarily mean that Prosody is fully ready to receive traffic.
By waiting until Prosody says it's ready via the systemd notify socket
we know for sure that Prosody is really ready.
Notably this should ensure that when running `make integration-test`
Prosody is really ready when Scansion starts running tests.
Not sure if this timeout handling is optimal.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Allows creating listening sockets and accepting client connections
before Prosody starts.
This is unlike normal Prosody dynamic resource management, where ports
may added and removed at any time, and the ports defined by the config.
Weird things happen if these are closed (e.g. due to reload) so here we
prevent closing and ensure sockets are reused when opened again.
|
|\| |
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Only supporting exact match on full JID isn't helpful if you want to
list sessions per host or user.
Backport of 430333198e4c
Fixes #1857
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
compliant behavior
From XEP-0191:
> For message stanzas, the server SHOULD return an error, which SHOULD
> be <service-unavailable/>.
Following this may leak to a blocked JID that they have been blocked,
which seems contrary to the goal of pretending to be perpetually
offline.
|
| |
| |
| |
| |
| |
| |
| | |
Allows e.g. restricting your vcard4 to only family or similar.
Notes: This does not include roster groups in the configuration form,
so the client will have to get them from the actual roster.
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
The code correctly inserted the ',' when there was already a "%q" in the
format string, but then the next argument would fail to match because it
inserted ", %q" instead of "%q". The code now matches both, ensuring the
generated code will not produce a syntax error with multiple arguments.
|
| |
| |
| |
| | |
Returning nothing/nil lets stanzas pass, returning anything else blocks
|
| |
| |
| |
| |
| | |
This ensures that someone on your blocklist is unable to invite you to MUC
rooms.
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
libunbound does not tell us the whole chain of CNAMEs, only the final
canonical name.
This is to aid in debugging since it will only be shown in the shell.
|
| |
| |
| |
| | |
Similar to 26c30844cac6
|
| |
| |
| |
| | |
Does this event name seem backwards to anyone else?
|
| |
| |
| |
| | |
`result[, err]`, not `ok, err|result`, must have confused it with pcall
|
| |
| |
| |
| |
| | |
The unstable hash table order caused the tests to fail and I don't know
how to tell scansion to ignore the order.
|
| |
| |
| |
| |
| | |
Discovered while experimenting with a stricter SystemCallFilter setting
See man:systemd.exec(5)
|
| |
| |
| |
| |
| |
| | |
This adds an output format option to show the time that the connection was created.
Ref #1852
|
|\| |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| |
| |
| |
| | |
Why do we not have tests for this?
|
| |
| |
| |
| | |
(thanks nicoco)
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
|\| |
|
| |
| |
| |
| |
| | |
This ensures that domain names of virtual hosts and components are valid in
XMPP, and that they are encoded correctly.
|
| |
| |
| |
| |
| | |
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.
|
| |
| |
| |
| |
| | |
This fixes a traceback with mod_saslauth. Ideally we move this to util.session
at some point, though.
|
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| | |
|
| | |
|
| |
| |
| |
| | |
Moved here from mod_posix since these events no longer originate there
|
| | |
|
| |
| |
| |
| | |
Reverts 4a9a69659727
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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 aid in tracking down signalfd-related problems
|
| | |
|