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

On Thu, Nov 25, 2010 at 12:27:50AM +0000, Amos Jeffries wrote:
> 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.

It looks like it's decided by whether or not you use the -N non-daemonise
startup flag. The auth sub processes always have STDERR correctly redirected
to cache_log, but without -N, the worker squid in the squid/root-squid pair
leaves no STDERR open for itself.

I'll get my farm using 'squid -N &' when they next hit a quiet period (and
I'm awake). This will also fix my HUP problem, the non-worker root-squid
does indeed drop dead on HUP.

squid 3.1.9 on Solaris 9 64bit btw.

DW

> Amos
Received on Thu Nov 25 2010 - 08:39:09 MST