> > Program received signal SIGHUP, Hangup.
Yes, I did not realized that I have executed 'squid -k reconfigure', hence that
SIGHUP signal.
I don not know if the following is relevant but:
When the exception occurred, I had executed (earlier) 'squid -k reconfigure'.
Then, I made a full squid sto
On 10/24/18 7:21 AM, Julian Perconti wrote:
> Program received signal SIGHUP, Hangup.
This is normal. Ideally, you should configure your gdb to ignore SIGHUP
and pass that signal to Squid.
> The crash (assertion failed)
>
> 2018/10/24 09:44:29| assertion failed: http.cc:1530:
> "!Comm::Monitor
> Hi Alex/Amos
>
> Since yesterday squid is running via this method in a cron script:
>
> trap "rm -f $$.gdb" 0
> cat <$$.gdb
> handle SIGPIPE pass nostop noprint
> handle SIGTERM pass nostop noprint
> handle SIGUSR1 pass nostop noprint
> handle SIGHUP pass
> handle SIGKILL pass
> handle SIGSEGV
> >> assertion failed: http.cc:1530: "!Comm::MonitorsRead(serverConnection-
> >fd)"
> >
> >> Any idea?
> >
> > Without the stack trace, it is difficult to say much about this bug.
> > Please collect a stack trace from the crash and post it to Squid
> > bugzilla. If the stack trace looks similar to
On 23/10/18 6:45 AM, Alex Rousskov wrote:
> On 10/22/18 8:38 AM, Julian Perconti wrote:
>
>> assertion failed: http.cc:1530: "!Comm::MonitorsRead(serverConnection->fd)"
>
>> Any idea?
>
> Without the stack trace, it is difficult to say much about this bug.
> Please collect a stack trace from the
On 10/22/18 8:38 AM, Julian Perconti wrote:
> assertion failed: http.cc:1530: "!Comm::MonitorsRead(serverConnection->fd)"
> Any idea?
Without the stack trace, it is difficult to say much about this bug.
Please collect a stack trace from the crash and post it to Squid
bugzilla. If the stack trace
