9ae72b0a23
Instead of searching for the asterisk binary and the modules in the
filesystem, we now get their locations, along with libdir, from
the coredump itself...
For the binary, we can use `gdb -c <coredump> ... "info proc exe"`.
gdb can print this even without having the executable and symbols.
Once we have the binary, we can get the location of the modules with
`gdb ... "print ast_config_AST_MODULE_DIR`
If there was no result then either it's not an asterisk coredump
or there were no symbols loaded. Either way, it's not usable.
For libdir, we now run "strings" on the note0 section of the
coredump (which has the shared library -> memory address xref) and
search for "libasteriskssl|libasteriskpj", then take the dirname.
Since we're now getting everything from the coredump, it has to be
correct as long as we're not crossing namespace boundaries like
running asterisk in a docker container but trying to run
ast_coredumper from the host using a shared file system (which you
shouldn't be doing).
There is still a case for using --asterisk-bin and/or --libdir: If
you've updated asterisk since the coredump was taken, the binary,
libraries and modules won't match the coredump which will render it
useless. If you can restore or rebuild the original files that
match the coredump and place them in a temporary directory, you can
use --asterisk-bin, --libdir, and a new --moddir option to point to
them and they'll be correctly captured in a tarball created
with --tarball-coredumps. If you also use --tarball-config, you can
use a new --etcdir option to point to what normally would be the
/etc/asterisk directory.
Also addressed many "shellcheck" findings.
Resolves: #445
(cherry picked from commit
|
||
---|---|---|
.. | ||
sip_to_pjsip | ||
README.messages-expire | ||
agents.php | ||
ast_coredumper | ||
ast_grab_core | ||
ast_logescalator | ||
ast_loggrabber | ||
ast_tls_cert | ||
astcli | ||
asterisk.ldap-schema | ||
asterisk.ldif | ||
asterisk.logrotate | ||
astgenkey | ||
astgenkey.8 | ||
astversion | ||
autosupport | ||
autosupport.8 | ||
clang-scan-build | ||
dahdi_span_config_hook | ||
dbsep.cgi | ||
file.convert.sh | ||
get_ilbc_source.sh | ||
get_mp3_source.sh | ||
get_swagger_ui.sh | ||
import-cdr-csv-mysql.pl | ||
install_prereq | ||
live_ast | ||
loadtest.tcl | ||
lookup.agi | ||
managerproxy.pl | ||
messages-expire.pl | ||
qview.pl | ||
refcounter.py | ||
reflocks.py | ||
refstats.py | ||
retrieve_extensions_from_mysql.pl | ||
retrieve_extensions_from_sql.pl | ||
retrieve_sip_conf_from_mysql.pl | ||
safe_asterisk | ||
safe_asterisk.8 | ||
safe_asterisk_restart | ||
sip_nat_settings | ||
sipp-sendfax.xml | ||
spandspflow2pcap.log | ||
spandspflow2pcap.py | ||
valgrind_compare | ||
vmail.cgi | ||
voicemailpwcheck.py |
README.messages-expire
messages-expire.pl messages-expire finds messages more than X days old and deletes them. Because the older messages will be the lower numbers in the folder (msg0000 will be older than msg0005), just deleting msg0000 will not work. expire-messages then runs a routine that goes into every folder in every mailbox to reorganize. If the folder contains msg0000, no action is taken. If the folder does not, the rename routine takes the oldest message and names it msg0000, the next oldest message and names it msg0001 and so on. The file deletion is done by the -exec parameter to 'find'. It would be far more efficient to take the output from 'find' and just reorganize the directories from which we deleted a file. Something for the future... Keep in mind that messages are deleted at the beginning of the script you will have mailbox trouble if you check messages before the script reorganizes your mailbox. To use it, make sure the paths are right. Adjust $age (originally set to 31) if necessary.