Sometimes while the debian repositories are updating there are
sporadic signature failures. It's annoying to have these break the
build, and the only thing to do is to retry, so we'll retry here
automatically. We were already retrying on the update operation that
can fail in a similar manner.
When -reincarnate-reexec is given we run execv to restart FS. If
argv[0] isn't a full pathname then execv is going to fail. While not
common for a FS system started by init, this is a common occurrence
when FS is started from the shell.
Now if execv fails, we'll try execvp. If that fails too then we'll
fall back on the normal reincarnation behavior.
Previously what would happen in that case is god would descend from
the heavens and become mortal. Leaving heaven absent, all hope for
reincarnation was lost.
(That is, we'd simply return from reincarnate_protect and the
supervisor process would become the new instance of FS, so the trick
would only work once.)
If you start freeswitch with -reincarnate or -reincarnate-reexec, FS
will restart automatically in the event of an unexpected exit.
Currently, you can cause FS to immediately call exit(0) with `fsctl
shutdown now`, or you can have it call abort() with `fsctl crash`.
Which are both nice, but if you have reincarnation engaged, you really
might want FS to call exit([non-zero]) so the great supervisor
immediately breathes life back into your system.
This is now available via `fsctl shutdown reincarnate now`.
What we momentarily called log-uuid-chars is now better called
log-uuid-length. Setting log-uuid-length will specify a truncation
length for UUIDs displayed by setting log-uuid.
If log-uuid-short is set, or -S is passed to fs_cli, we only display
the first 8 hex digits of the UUID. The log-uuid-chars option may
instead be set to specify some other truncation length for the UUID.
If FS is not behind NAT, then every call generates at least three
INFO-level log messages:
[INFO] switch_nat.c:589 NAT port mapping disabled
This is useless noise. The message is only interesting if you do have
NAT enabled but mapping disabled, which might indicate a configuration
issue.
With this change, we just skip the entire nat_add_mapping function if
the NAT system isn't initialized or we're not behind NAT.
Putting `net-snmp-config --cflags` into CFLAGS causes major pollution;
it overrides optimization and debugging levels, warnings, and more.
While normally we do want to automatically locate library headers,
there has to be a better way to do this. libsnmp is normally in the
usual place and doesn't need special handling. Perhaps people with
libsnmp in a weird place should just need to add the -I flag to their
CFLAGS before build.
Calling out to net-snmp-config --agent-libs causes transitive
dependencies to get pulled in, but we don't need those -- a sensible
dynamic linker pulls those in automatically. Trying to track the
transitive dependencies manually would be a losing battle.
People were recently hitting this on Debian sid/jessie, where libpci
is in the transitive dependency list but isn't otherwise one of our
build dependencies.
