This fixes a possibility for MAX_MISSED to be exceeded if more logs are
attempted to be pushed to the listener's queue after running kill_listener but
before the listener thread gets CPU time and removes itself.
On a heavily loaded system with a lot of logs in the event dispatch queue
these excessive logs may prove fatal since socket_logger itself will produce
logs about the full queue, resulting in a circular situation of never-ending logs.
The same logic was applied to event_handler after finding the same behaviour
mentioned in signalwire/freeswitch#2143.
* switch_time: fix segfault null TIMEZONES_LIST.hash when reloading xml
* Unbind before destroying TIMEZONES_LIST.hash. Protect TIMEZONES_LIST.hash with a mutex that's allocated in core's global runtime.memory_pool so the mutex does not die on softtimer shutdown.
---------
Co-authored-by: Andrey Volk <andywolk@gmail.com>
* [mod_amqp] Adjusting to Appropriate Log Level for Message
Refined Logging Level for FreeSWITCH's mod_amqp: The logging level for the AMQP module in FreeSWITCH has been updated from 'warning' to 'debug'. This adjustment ensures a more suitable level for the log message and eliminates any potential impact on production environments. Previously, the 'warning' level would lead to unnecessary log entries for each individual message, although there was no actual warning condition. This change improves logging efficiency and appropriateness for mod_amqp's operations within FreeSWITCH.
* [MOD_AMQP] Change LogLevel to DEBUG1 as it is more appropriate for this message
* [ldns] config.h change to not define inline under Windows to avoid clash with Windows winsock2.h inline usage
* [Build-System] Use updated ldns tarball on Windows.
---------
Co-authored-by: Andrey Volk <andywolk@gmail.com>
On several installs on recent Debian and Ubuntu systems, I have noticed
that GID 999 is already allocated on the system running the container,
making it a minor hassle to share a common freeswitch UID and GID
between the Docker host and the container.
The conflicting group id varies, but is typically either one of the systemd
groups or polkitd, which are dynamically created when those packages are
installed. The behavior stems from the range of system GIDs being
between 100-999 ([see Debian Policy 9.2.2](https://www.debian.org/doc/debian-policy/ch-opersys.html#uid-and-gid-classes))
and the fact that system installation dynamically allocates from this
range. I didn't track down exactly why these daemons are allocating
from the top of the range, since the default behavior of `adduser` and
`addgroup` ([link](6c04aa701a/adduser (L1255-1269)))
is to search from the bottom of the range, and the manpage for
`groupadd` says that it's default is also to use the smallest id,
but perhaps it was to avoid (other) conflicts.
The approach taken in this PR is to default to 499, more in the middle
of the range, which should reduce the chance of conflicting with an
existing system UID and GID. The values are also now exposed as ARGs
and so can be explicitly set during the build with
`--build-arg="FREESWITCH_UID=xxx"` and `--build-arg="FREESWITCH_GID=yyy"`
if desired.
Andrey Volk
Jakub Karolczyk
Hadžem Hadžić
s3rj1k
Anton Olofsson
Dragos Oancea
wmasilva
Dmitry Kunilov
mahald
Visytel
tmancill