| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
By aborting early, the failure should be brought to the attention
somehow.
|
|
|
|
| |
To make any such failures noticeable
|
|\ |
|
| |
| |
| |
| | |
Fixes error in #1765 by throwing an error earlier
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
Yeah, it's weird to have two versions. Needing more build dependencies
is also something we want to avoid, so here we are.
|
| | |
|
| |
| |
| |
| |
| |
| | |
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.
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| | |
This allows multiple modules to populate the form dynamically. Currently the
form is "owned" by mod_server_contact_info, which prevents other modules from
contributing to it.
A further commit will port mod_server_contact_info to use this module.
|
| | |
|
| |
| |
| |
| | |
Also sorted to match C source
|
| |
| |
| |
| |
| |
| | |
Was missing some entries.
Rearranged to match order of entries in the C source Reg table.
|
| | |
|
| |
| |
| |
| | |
100,000 iterations of match() on my laptop from 3.5s -> 0.5s.
|
| | |
|
| |
| |
| |
| |
| | |
This returns the number of bits that two strings have in common. It is
significantly more efficient than similar calculations in Lua.
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| | |
It was mainly used to determine whether to try IPv6 or IPv4 first,
following the rules for this in the RFC.
Now we always try IPv6 and IPv4 at roughly the same time, thus there no
need to carry these rules.
|
| | |
|
| |
| |
| |
| | |
for convenience.
|
| |
| |
| |
| |
| | |
conn:ssl_peerverification() can now return a single error in case the
connection has been closed for whatever reason
|
| |
| |
| |
| | |
Unclear why this would be done, but an error is not great.
|
| |
| |
| |
| |
| | |
Notably, it is now possible to add a randomized spread factor to the check
interval.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Given that there are recommendations floating around recommending 24
hours session lifetime, having buckets up to 10 minutes wouldn't be
useful in that case.
Would be nice if we had some way to automatically assign suitable number
series for buckets, scaled to what the configuration might be.
|
| |
| |
| |
| |
| | |
Fixes a test case provided by MattJ where the very first item matched by
a 'start' timestamp was not returned.
|
| |
| |
| |
| | |
Moves some complexity from the implementation into DNS operations.
|
| |
| |
| |
| | |
Fewer loops
|
| | |
|
| |
| |
| |
| |
| | |
Ref #667
Ref #1838
|
| |
| |
| |
| |
| | |
Not sure what the next() was supposed to do. Reject unknown --options
perhaps?
|