[jira] [Updated] (TS-2970) Multiple crashes when using tr-pass
[
https://issues.apache.org/jira/browse/TS-2970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolai Gorchilov updated TS-2970:
--
Summary: Multiple crashes when using tr-pass (was: Different crashes when
using tr-pass)
> Multiple crashes when using tr-pass
> ---
>
> Key: TS-2970
> URL: https://issues.apache.org/jira/browse/TS-2970
> Project: Traffic Server
> Issue Type: Bug
> Components: Core, HTTP
>Affects Versions: 5.0.0, 5.0.1
>Reporter: Nikolai Gorchilov
>
> ATS 5.0.1 Running under Linux 3+ kernel in TPROXY mode.
> Same configuration runs without a single crash for weeks, but in the moment I
> enable tr-pass (8081:ip-in=127.0.0.1:tr-ful:tr-pass) on server_ports I get
> many crashes in matter of seconds to minutes after starting the ATS:
> {noformat}
> FATAL: HttpSM.cc:2714: failed assert `event == HTTP_TUNNEL_EVENT_DONE`
> /z/bin/traffic_server - STACK TRACE:
> /z/lib/libtsutil.so.5(ink_fatal_die+0x0)[0x2b52382e8067]
> /z/lib/libtsutil.so.5(ink_get_rand()+0x0)[0x2b52382e6b28]
> /z/bin/traffic_server(HttpSM::tunnel_handler(int, void*)+0x148)[0x5cf9aa]
> /z/bin/traffic_server(HttpSM::main_handler(int, void*)+0x333)[0x5cebeb]
> /z/bin/traffic_server(Continuation::handleEvent(int, void*)+0x68)[0x4f089a]
> /z/bin/traffic_server(CheckConnect::handle_connect(int,
> Event*)+0x2f0)[0x74313c]
> /z/bin/traffic_server(Continuation::handleEvent(int, void*)+0x68)[0x4f089a]
> /z/bin/traffic_server[0x743c82]
> /z/bin/traffic_server(write_to_net_io(NetHandler*, UnixNetVConnection*,
> EThread*)+0x389)[0x7449c3]
> /z/bin/traffic_server(write_to_net(NetHandler*, UnixNetVConnection*,
> EThread*)+0x79)[0x744638]
> /z/bin/traffic_server(NetHandler::mainNetEvent(int, Event*)+0x6f3)[0x73dc21]
> /z/bin/traffic_server(Continuation::handleEvent(int, void*)+0x68)[0x4f089a]
> /z/bin/traffic_server(EThread::process_event(Event*, int)+0x11e)[0x7664ca]
> /z/bin/traffic_server(EThread::execute()+0x45b)[0x766aa1]
> /z/bin/traffic_server[0x76598f]
> /lib64/libpthread.so.0(+0x7034)[0x2b52398f4034]
> /lib64/libc.so.6(clone+0x6d)[0x2b523a63eb5d]
> {noformat}
> {noformat}
> FATAL: HttpSM.cc:1687: failed assert `0`
> /z/bin/traffic_server - STACK TRACE:
> /z/lib/libtsutil.so.5(+0x1e837)[0x2b6545caa837]
> /z/lib/libtsutil.so.5(+0x1d51f)[0x2b6545ca951f]
> /z/bin/traffic_server(HttpSM::state_http_server_open(int,
> void*)+0xfd)[0x5a13cd]
> /z/bin/traffic_server(HttpSM::main_handler(int, void*)+0xd8)[0x59ac88]
> /z/bin/traffic_server[0x65313a]
> /z/bin/traffic_server(HostDBContinuation::probeEvent(int,
> Event*)+0x27a)[0x65967a]
> /z/bin/traffic_server(EThread::process_event(Event*, int)+0x91)[0x736071]
> /z/bin/traffic_server(EThread::execute()+0x2fb)[0x73692b]
> /z/bin/traffic_server[0x73530a]
> /lib64/libpthread.so.0(+0x7034)[0x2b65472b0034]
> /lib64/libc.so.6(clone+0x6d)[0x2b6547ffab5d]
> {noformat}
> {noformat}
> FATAL: HttpTunnel.cc:554: failed assert `active == false`
> /z/bin/traffic_server - STACK TRACE:
> /z/lib/libtsutil.so.5(+0x1e837)[0x2b679373e837]
> /z/lib/libtsutil.so.5(+0x1d51f)[0x2b679373d51f]
> /z/bin/traffic_server[0x5d660f]
> /z/bin/traffic_server(HttpSM::kill_this()+0x674)[0x59a974]
> /z/bin/traffic_server(HttpSM::main_handler(int, void*)+0x148)[0x59acf8]
> /z/bin/traffic_server(CheckConnect::handle_connect(int,
> Event*)+0x119)[0x70d659]
> /z/bin/traffic_server(UnixNetVConnection::mainEvent(int,
> Event*)+0x3f0)[0x716640]
> /z/bin/traffic_server(InactivityCop::check_inactivity(int,
> Event*)+0x275)[0x708045]
> /z/bin/traffic_server(EThread::process_event(Event*, int)+0x91)[0x736071]
> /z/bin/traffic_server(EThread::execute()+0x2fb)[0x73692b]
> /z/bin/traffic_server[0x73530a]
> /lib64/libpthread.so.0(+0x7034)[0x2b6794d44034]
> /lib64/libc.so.6(clone+0x6d)[0x2b6795a8eb5d]
> {noformat}
> My configure options other than layout-related are:
> {noformat}
> --with-group=proxy \
> --with-xml=libxml2 \
> --disable-static \
> --disable-static-libts \
> --disable-spdy \
> --enable-interim-cache \
> --enable-tproxy \
> --enable-hwloc \
> --enable-experimental-plugins \
> --enable-example-plugins
> {noformat}
> P.S. Report updated due to some --enable-debug related crashes, that weren't
> connected to tr-pass at all
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2972) authproxy: Investigate if we can run this (configurable) in a different hook
[ https://issues.apache.org/jira/browse/TS-2972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14081000#comment-14081000 ] Leif Hedstrom commented on TS-2972: --- So, it seems running it in TS_HTTP_CACHE_LOOKUP_COMPLETE_HOOK makes things peachy. I was going to make this optional (which would make it possible to behave as it does today), but got some negative feedback on that. Does anyone have concerns about changing this plugin such that it always does the "auth proxy" phase (external request), even on cache hits? > authproxy: Investigate if we can run this (configurable) in a different hook > > > Key: TS-2972 > URL: https://issues.apache.org/jira/browse/TS-2972 > Project: Traffic Server > Issue Type: Improvement > Components: Plugins >Reporter: Leif Hedstrom >Assignee: Leif Hedstrom > Fix For: 5.1.0 > > > The issue is that without a (global) configuration to force us to go through > the DNS hook on cache hits, we can not use authproxy to protect on cache hits > (the plugin is bypassed). > The setting is proxy.config.http.doc_in_cache_skip_dns, and it was added for > a very valid reason: If the entry in HostDB is stale, we can not serve out of > cache while it's doing the DNS lookup. This blocks all requests on that URL > until DNS has finished, which in some cases can take a long time (we had a > problem where some 3rd party DNS vendor could take up to 1s to resolve). > My idea / hope is to make authproxy support running in a different hook, such > that it always can get called. However, the wrinkle is that this is also a > remap plugin, so whatever hook we pick, it has to happen after remap. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2972) authproxy: Investigate if we can run this (configurable) in a different hook
[ https://issues.apache.org/jira/browse/TS-2972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14081070#comment-14081070 ] ASF subversion and git services commented on TS-2972: - Commit 4b2429b60b65cbe13dc59fe7fb9c8e12a436af84 in trafficserver's branch refs/heads/master from [~zwoop] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=4b2429b ] TS-2972 Fix indentation as per our coding standards > authproxy: Investigate if we can run this (configurable) in a different hook > > > Key: TS-2972 > URL: https://issues.apache.org/jira/browse/TS-2972 > Project: Traffic Server > Issue Type: Improvement > Components: Plugins >Reporter: Leif Hedstrom >Assignee: Leif Hedstrom > Fix For: 5.1.0 > > > The issue is that without a (global) configuration to force us to go through > the DNS hook on cache hits, we can not use authproxy to protect on cache hits > (the plugin is bypassed). > The setting is proxy.config.http.doc_in_cache_skip_dns, and it was added for > a very valid reason: If the entry in HostDB is stale, we can not serve out of > cache while it's doing the DNS lookup. This blocks all requests on that URL > until DNS has finished, which in some cases can take a long time (we had a > problem where some 3rd party DNS vendor could take up to 1s to resolve). > My idea / hope is to make authproxy support running in a different hook, such > that it always can get called. However, the wrinkle is that this is also a > remap plugin, so whatever hook we pick, it has to happen after remap. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2978) Reorder member variables in HttpSM State
[ https://issues.apache.org/jira/browse/TS-2978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2978: -- Issue Type: Improvement (was: Bug) > Reorder member variables in HttpSM State > > > Key: TS-2978 > URL: https://issues.apache.org/jira/browse/TS-2978 > Project: Traffic Server > Issue Type: Improvement > Components: HTTP >Reporter: Leif Hedstrom > Fix For: 5.1.0 > > > I think we can reduce its size by reordering for example the booleans such > that we don't have to pad so much ? -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (TS-2978) Reorder member variables in HttpSM State
[ https://issues.apache.org/jira/browse/TS-2978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-2978: - Assignee: Leif Hedstrom > Reorder member variables in HttpSM State > > > Key: TS-2978 > URL: https://issues.apache.org/jira/browse/TS-2978 > Project: Traffic Server > Issue Type: Improvement > Components: HTTP >Reporter: Leif Hedstrom >Assignee: Leif Hedstrom > Fix For: 5.1.0 > > > I think we can reduce its size by reordering for example the booleans such > that we don't have to pad so much ? -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TS-2978) Reorder member variables in HttpSM State
Leif Hedstrom created TS-2978: - Summary: Reorder member variables in HttpSM State Key: TS-2978 URL: https://issues.apache.org/jira/browse/TS-2978 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: Leif Hedstrom I think we can reduce its size by reordering for example the booleans such that we don't have to pad so much ? -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2978) Reorder member variables in HttpSM State
[ https://issues.apache.org/jira/browse/TS-2978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2978: -- Fix Version/s: 5.1.0 > Reorder member variables in HttpSM State > > > Key: TS-2978 > URL: https://issues.apache.org/jira/browse/TS-2978 > Project: Traffic Server > Issue Type: Improvement > Components: HTTP >Reporter: Leif Hedstrom > Fix For: 5.1.0 > > > I think we can reduce its size by reordering for example the booleans such > that we don't have to pad so much ? -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2967) failed assert if ssl_multicert.config doesn't exist
[
https://issues.apache.org/jira/browse/TS-2967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14081562#comment-14081562
]
James Peach commented on TS-2967:
-
0 is an invalid config index, so {{ConfigProcessor::get}} will return NULL for
that. The only place I can see that needs a NULL check is
{{SSLNetVConnection::sslStartHandShake}}.
> failed assert if ssl_multicert.config doesn't exist
> ---
>
> Key: TS-2967
> URL: https://issues.apache.org/jira/browse/TS-2967
> Project: Traffic Server
> Issue Type: Bug
>Reporter: Jack Bates
>
> If an ssl_multicert.config file doesn't exist then
> SSLParseCertificateConfiguration() returns false (SSLUtils.cc line 1435)
> and SSLCertificateConfig::reconfigure() doesn't initialize configid
> (SSLConfig.cc line 333)
> Then when SSLRecRawStatSyncCount() calls SSLCertificateConfig::acquire()
> (SSLUtils.cc line 502)
> it calls ConfigProcessor::get() with configid zero (SSLConfig.cc line 342)
> and there's an ink_assert(id != 0) (ProxyConfig.cc line 175)
> One way to avoid the failed assert is if SSLCertificateConfig::acquire() and
> SSLCertificateConfig::release() only call ConfigProcessor::get/release() if
> (configid !=0)
> Another way might be if SSLCertificateConfig::reconfigure() initialized
> configid with configProcessor.set(configid, NULL) if
> SSLParseCertificateConfiguration() returns false?
> Or SSLParseCertificateConfiguration() could treat a nonexistent
> ssl_multicert.config the same as it treats a blank file? ({{touch
> ssl_multicert.config}} makes the failed assert go away.)
> Or maybe there's another better way to avoid the failed assert?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2966) Update Feature not working
[
https://issues.apache.org/jira/browse/TS-2966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14081666#comment-14081666
]
James Peach commented on TS-2966:
-
The patch adds a NULL check for {{HttpSM::ua_session}}, but {{ua_session}}
should not be NULL at this point. Maybe there's some condition that is only
triggered by the update state machine.
I took a look at the update code and it doesn't look too promising. I think it
will be some work to bring it to life and get it nicely tested. I'm happy to
review and land patches.
> Update Feature not working
> --
>
> Key: TS-2966
> URL: https://issues.apache.org/jira/browse/TS-2966
> Project: Traffic Server
> Issue Type: Bug
> Components: Cache, Core
>Reporter: Thomas Stinner
> Fix For: sometime
>
> Attachments: traffic.out, trafficserver.patch
>
>
> I had a problem using the update feature. I recevied a SegFault in
> do_host_db_lookup which was caused by accessing ua_session which was not
> initialized (see attached patch).
> After fixing that i no longer get an SegFault, but the files that are
> retrieved by recursion are not placed into the cache. They are requested in
> every schedule.
> Only the starting file is placed correctly into the cache.
> When retrieving the files with a client, caching works as expected. So i
> don't think this is a configuration error.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2966) Update Feature not working
[ https://issues.apache.org/jira/browse/TS-2966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-2966: Component/s: Core Fix Version/s: sometime Pushing to "sometime". I cancelled the patch because I think the crash here is just a symptom of deeper problems with the update state machine. > Update Feature not working > -- > > Key: TS-2966 > URL: https://issues.apache.org/jira/browse/TS-2966 > Project: Traffic Server > Issue Type: Bug > Components: Cache, Core >Reporter: Thomas Stinner > Fix For: sometime > > Attachments: traffic.out, trafficserver.patch > > > I had a problem using the update feature. I recevied a SegFault in > do_host_db_lookup which was caused by accessing ua_session which was not > initialized (see attached patch). > After fixing that i no longer get an SegFault, but the files that are > retrieved by recursion are not placed into the cache. They are requested in > every schedule. > Only the starting file is placed correctly into the cache. > When retrieving the files with a client, caching works as expected. So i > don't think this is a configuration error. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2367) Add OCSP (Online Certificate Status Protocol) Stapling Support
[ https://issues.apache.org/jira/browse/TS-2367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14081681#comment-14081681 ] James Peach commented on TS-2367: - Thanks! I'll review tomorrow. > Add OCSP (Online Certificate Status Protocol) Stapling Support > --- > > Key: TS-2367 > URL: https://issues.apache.org/jira/browse/TS-2367 > Project: Traffic Server > Issue Type: New Feature > Components: HTTP, SSL >Reporter: Bryan Call >Assignee: Bryan Call > Labels: review > Fix For: 5.1.0 > > Attachments: TS-2367.diff, TS-2367.diff > > > RFC: > http://tools.ietf.org/html/rfc6066 > Overview: > https://wiki.mozilla.org/Security/Server_Side_TLS#OCSP_Stapling > http://en.wikipedia.org/wiki/OCSP_stapling > There is support for this added into openssl 0.9.8g. -- This message was sent by Atlassian JIRA (v6.2#6252)
