On 12/09/2015 04:38 PM, Marcus Kool wrote: >> On 12/09/2015 02:28 PM, Amos Jeffries wrote: >>> The above >>> considerations are all good reasons for us not to be bundling by default >>> IMO.
> I did not get what the script does, does it call gdb ? The *sample* script I attached collects information such as /proc/meminfo and /proc/PID/status. It is possible to write a script that attaches gdb to the dying Squid process (useful for debugging shared memory areas that cannot be looked at when examining the core file post-mortem). However, just sleeping until some /tmp/ file is touched would be better for interactive debugging because the admin can attach gdb herself, from her favourite terminal, etc. I do not propose making Squid run any script/handler by default. > A script/executable that calls gdb and produces a readable stack trace > of all squid processes is a powerful tool which makes debugging an issue > much easier for many admins. > So I suggest to release the binaries and scripts that you have, install > them by default in a new subdirectory, e.g. .../debugbin or > .../sbin/debug, and _not_ configure them in the default squid.conf to > prevent them being used accidentally. I do not recommend that because of the security risks and maintenance overheads -- if we install something, we are responsible for it. However, I would not object if others are sure it is a great idea. FWIW, AFAIK, it is possible to dump the backtrace from within Squid process itself (where it is supported by GNU libraries, I guess). > If you do not want to bundle, then what is the alternative? > Make a download area on squid-cache.org for the binaries and scripts ? Yes, folks can always post them on wiki.squid-cache.org. Thank you, Alex. _______________________________________________ squid-dev mailing list [email protected] http://lists.squid-cache.org/listinfo/squid-dev
