Re: [squid-users] STDERR is closed? So no std::cerr?

On Wed, 24 Nov 2010 13:26:03 +0000, Declan White <declanw_at_is.bbc.co.uk>
wrote:
> I've got some 'uncaught exception' coredumping squids which are leaving
no
> clues about their deaths.
> They are *meant* to be sending an SOS via:
>
> main.cc:1162: std::cerr << "dying from an unhandled exception: "
<<
> e.what() << std::endl;
>
> but std::cerr isn't the cache_log is it. It's STDERR, aka FD 2.
>
> COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
> squid 22444 squid 2u VCHR 13,2 0t0 3398
> /devices/pseudo/mm_at_0:null
>
> .. which according to lsof has been /dev/nulled, which is odd, as I had
it
> redirected to a file when it was started.
>
> Should the fallback exception handler not be using another reporting
> channel?
>
> I also notice that the root parent squid which waits for the child
> eventually disappears, after restarting crashes, making the next crash
> fatal. Is that normal? Does it react badly if it catches a HUP sent by a
> 'pkill -HUP squid' ?
>
> DW

hmm, how many and what particular processes are running? which particular
sub-process(es) is this happening to? how are you starting squid? etc. etc.

For background, by default only the master process uses stderr as itself.
All sub-processes have their stderr redirected to cache.log.

Amos
Received on Thu Nov 25 2010 - 00:27:55 MST