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.
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.
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
Handling signal events the same way as all other events makes sense and
seems safer than the signal handling just jumping around in C and
messing with Lua states.
signalfd allows handling signal events using the same method as sockets,
via file descriptors. Thus all signal dispatch can go through the same
main event loop as everything else, removing need for thread-scary
signal handling where execution would just jump to the signal handler
regardless of the state of Lua, and needing to keep track of Lua
states/threads.
