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

"dying from an unhandled exception: !theConsumer"

Hurrah! Caught the STDERR message via non-daemonised mode!
Now I just have to find out what that means :)

On Thu, Nov 25, 2010 at 08:39:05AM +0000, declanw_at_is.bbc.co.uk wrote:
> 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.
[...]
> > 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

DW
Received on Fri Nov 26 2010 - 12:16:22 MST