1a0acabb8a
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 |
||
|---|---|---|
| .. | ||
| 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 | ||
| safe_asterisk | ||
| safe_asterisk.8 | ||
| safe_asterisk_restart | ||
| 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.