[squid-dev] [RFC] on_crash

[Alex Rousskov]

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.