[jira] [Commented] (TS-2372) Add forward secrecy support (SSL related)
[ https://issues.apache.org/jira/browse/TS-2372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13837422#comment-13837422 ] Jan-Frode Myklebust commented on TS-2372: - Disabling SSLv3 breaks IE6, which is still used by almost 5% of the desktop clients according to http://marketshare.hitslink.com/browser-market-share.aspx?qprid=2qpcustomd=0 Add forward secrecy support (SSL related) - Key: TS-2372 URL: https://issues.apache.org/jira/browse/TS-2372 Project: Traffic Server Issue Type: Improvement Components: HTTP Reporter: Bryan Call Assignee: James Peach Labels: ssl Fix For: 4.2.0 mod_ssl bug and changes: https://issues.apache.org/bugzilla/show_bug.cgi?id=49559 Discussion on httpd-dev list: http://mail-archives.apache.org/mod_mbox/httpd-dev/201309.mbox/%3c52358ed1.2070...@velox.ch%3E -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (TS-2372) Add forward security support (SSL related)
[ https://issues.apache.org/jira/browse/TS-2372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13832012#comment-13832012 ] Jan-Frode Myklebust commented on TS-2372: - Adam Langley has an argument for supporting DHE in addition to ECDHE, ref: https://www.imperialviolet.org/2013/10/07/chacha20.html ... As a last attempt, they'll try an SSLv3 connection with no extensions. Several useful features get jettisoned when this occurs but the important one for security, up until now, has been that elliptic curve support is disabled in SSLv3. For servers that support ECDHE but not DHE that means that a network attacker can trigger version downgrades and remove forward security from a connection. Add forward security support (SSL related) -- Key: TS-2372 URL: https://issues.apache.org/jira/browse/TS-2372 Project: Traffic Server Issue Type: Improvement Components: HTTP Reporter: Bryan Call Assignee: James Peach Labels: ssl Fix For: 4.2.0 mod_ssl bug and changes: https://issues.apache.org/bugzilla/show_bug.cgi?id=49559 Discussion on httpd-dev list: http://mail-archives.apache.org/mod_mbox/httpd-dev/201309.mbox/%3c52358ed1.2070...@velox.ch%3E -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (TS-2392) Enable elliptic curve ciphers to support forward secrecy
[
https://issues.apache.org/jira/browse/TS-2392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan-Frode Myklebust updated TS-2392:
Description:
ATS does not seem to support the elliptic curve diffie hellman ephemeral key
exchanges (ECDH) that are available in openssl. It seems these needs to be
enabled explicitly to take advantage of them. Ref: the following commit for how
this support was added to apache httpd v2.3.3:
http://mail-archives.apache.org/mod_mbox/httpd-cvs/200911.mbox/%3c20091110075514.166a62388...@eris.apache.org%3E
and for stud:
https://github.com/bumptech/stud/pull/61/files
Maybe both a DH key exchange needs to be set up, and then the various elliptic
curves needs to be initialized..?
Checking the openssl docs, I see SSL_CTX_set_tmp_dh_callback() needs to be
called to set up the ephemeral keys:
http://www.openssl.org/docs/ssl/SSL_CTX_set_tmp_dh_callback.html
https://tech.immerda.ch/2011/11/the-state-of-forward-secrecy-in-openssl/
http://wiki.openssl.org/index.php/Elliptic_Curve_Diffie_Hellman
And these are the named curves available with openssl-1.0.1e-16.el6_5.x86_64 on
RHEL-6.5:
{noformat}
$ openssl ecparam -list_curves
secp384r1 : NIST/SECG curve over a 384 bit prime field
prime256v1: X9.62/SECG curve over a 256 bit prime field
{noformat}
was:
ATS does not seem to support the elliptic curve diffie hellman ephemeral key
exchanges (ECDH) that are available in openssl. It seems these needs to be
enabled explicitly to take advantage of them. Ref: the following commit for how
this support was added to apache httpd v2.3.3:
http://mail-archives.apache.org/mod_mbox/httpd-cvs/200911.mbox/%3c20091110075514.166a62388...@eris.apache.org%3E
and for stud:
https://github.com/bumptech/stud/pull/61/files
Maybe both a DH key exchange needs to be set up, and then the various elliptic
curves needs to be initialized..?
Checking the openssl docs, I see SSL_CTX_set_tmp_dh_callback() needs to be
called to set up the ephemeral keys:
http://www.openssl.org/docs/ssl/SSL_CTX_set_tmp_dh_callback.html
https://tech.immerda.ch/2011/11/the-state-of-forward-secrecy-in-openssl/
Enable elliptic curve ciphers to support forward secrecy
Key: TS-2392
URL: https://issues.apache.org/jira/browse/TS-2392
Project: Traffic Server
Issue Type: Improvement
Components: SSL
Reporter: Jan-Frode Myklebust
ATS does not seem to support the elliptic curve diffie hellman ephemeral key
exchanges (ECDH) that are available in openssl. It seems these needs to be
enabled explicitly to take advantage of them. Ref: the following commit for
how this support was added to apache httpd v2.3.3:
http://mail-archives.apache.org/mod_mbox/httpd-cvs/200911.mbox/%3c20091110075514.166a62388...@eris.apache.org%3E
and for stud:
https://github.com/bumptech/stud/pull/61/files
Maybe both a DH key exchange needs to be set up, and then the various
elliptic curves needs to be initialized..?
Checking the openssl docs, I see SSL_CTX_set_tmp_dh_callback() needs to be
called to set up the ephemeral keys:
http://www.openssl.org/docs/ssl/SSL_CTX_set_tmp_dh_callback.html
https://tech.immerda.ch/2011/11/the-state-of-forward-secrecy-in-openssl/
http://wiki.openssl.org/index.php/Elliptic_Curve_Diffie_Hellman
And these are the named curves available with openssl-1.0.1e-16.el6_5.x86_64
on RHEL-6.5:
{noformat}
$ openssl ecparam -list_curves
secp384r1 : NIST/SECG curve over a 384 bit prime field
prime256v1: X9.62/SECG curve over a 256 bit prime field
{noformat}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Created] (TS-2298) 400 Multi-Hop Cycle detected with .insert_request_via_str
Jan-Frode Myklebust created TS-2298:
---
Summary: 400 Multi-Hop Cycle detected with .insert_request_via_str
Key: TS-2298
URL: https://issues.apache.org/jira/browse/TS-2298
Project: Traffic Server
Issue Type: Bug
Components: Core
Reporter: Jan-Frode Myklebust
We're seeing 400 Multi-Hop Cycle detected problems when
proxy.config.http.insert_request_via_str is enabled. We see the same problem on
both v4.0.2, v3.2.3 and v3.2.5.
The configuration we have that triggers this is:
{noformat}
map http://www.example.com/http://web1.example.net/
map https://api.example.com http://api1.examle.net/
{noformat}
where web1.example.net is using mod_proxy to proxy some requests to
https://api.services.example.com:
{noformat}
SSLProxyEngine On
ProxyPass /api/menu https://api.example.com/test/api/menu
{noformat}
If we www.example.com and api.example.com is going trough the same
trafficserver with proxy.config.http.insert_request_via_str enabled we get the
Multi-Hop Cycle detected error. If they are going trough different physical
hosts, or if we disable proxy.config.http.insert_request_via_str then the
problem goes away.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (TS-2298) 400 Multi-Hop Cycle detected with .insert_request_via_str
[
https://issues.apache.org/jira/browse/TS-2298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan-Frode Myklebust updated TS-2298:
Description:
We're seeing 400 Multi-Hop Cycle detected problems when
proxy.config.http.insert_request_via_str is enabled. We see the same problem on
both v4.0.2, v3.2.3 and v3.2.5.
The configuration we have that triggers this is:
{noformat}
map http://www.example.com/http://web1.example.net/
map https://api.example.com http://api1.examle.net/
{noformat}
where web1.example.net is using mod_proxy to proxy some requests to
https://api.services.example.com:
{noformat}
SSLProxyEngine On
ProxyPass /api/menu https://api.example.com/test/api/menu
{noformat}
If www.example.com and api.example.com is going trough the same trafficserver
with proxy.config.http.insert_request_via_str enabled we get the Multi-Hop
Cycle detected error. If they are going trough different physical hosts, or if
we disable proxy.config.http.insert_request_via_str then the problem goes away.
was:
We're seeing 400 Multi-Hop Cycle detected problems when
proxy.config.http.insert_request_via_str is enabled. We see the same problem on
both v4.0.2, v3.2.3 and v3.2.5.
The configuration we have that triggers this is:
{noformat}
map http://www.example.com/http://web1.example.net/
map https://api.example.com http://api1.examle.net/
{noformat}
where web1.example.net is using mod_proxy to proxy some requests to
https://api.services.example.com:
{noformat}
SSLProxyEngine On
ProxyPass /api/menu https://api.example.com/test/api/menu
{noformat}
If we www.example.com and api.example.com is going trough the same
trafficserver with proxy.config.http.insert_request_via_str enabled we get the
Multi-Hop Cycle detected error. If they are going trough different physical
hosts, or if we disable proxy.config.http.insert_request_via_str then the
problem goes away.
Environment: RHEL6, x86_64, apache httpd, mod_proxy
Affects Version/s: 3.2.5
4.0.2
400 Multi-Hop Cycle detected with .insert_request_via_str
-
Key: TS-2298
URL: https://issues.apache.org/jira/browse/TS-2298
Project: Traffic Server
Issue Type: Bug
Components: Core
Affects Versions: 3.2.5, 4.0.2
Environment: RHEL6, x86_64, apache httpd, mod_proxy
Reporter: Jan-Frode Myklebust
We're seeing 400 Multi-Hop Cycle detected problems when
proxy.config.http.insert_request_via_str is enabled. We see the same problem
on both v4.0.2, v3.2.3 and v3.2.5.
The configuration we have that triggers this is:
{noformat}
map http://www.example.com/http://web1.example.net/
map https://api.example.com http://api1.examle.net/
{noformat}
where web1.example.net is using mod_proxy to proxy some requests to
https://api.services.example.com:
{noformat}
SSLProxyEngine On
ProxyPass /api/menu https://api.example.com/test/api/menu
{noformat}
If www.example.com and api.example.com is going trough the same
trafficserver with proxy.config.http.insert_request_via_str enabled we get
the Multi-Hop Cycle detected error. If they are going trough different
physical hosts, or if we disable proxy.config.http.insert_request_via_str
then the problem goes away.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (TS-2298) 400 Multi-Hop Cycle detected with .insert_request_via_str
[
https://issues.apache.org/jira/browse/TS-2298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan-Frode Myklebust updated TS-2298:
Description:
We're seeing 400 Multi-Hop Cycle detected problems when
proxy.config.http.insert_request_via_str is enabled. We see the same problem on
both v4.0.2, v3.2.3 and v3.2.5.
The configuration we have that triggers this is:
{noformat}
map http://www.example.com/http://web1.example.net/
map http://api.example.com http://api1.example.net/
{noformat}
where web1.example.net is using mod_proxy to proxy some requests to
http://api.example.com:
{noformat}
ProxyPass /api/menu http://api.example.com/test/api/menu
{noformat}
If www.example.com and api.example.com is going trough the same trafficserver
with proxy.config.http.insert_request_via_str enabled we get the Multi-Hop
Cycle detected error. If they are going trough different physical hosts, or if
we disable proxy.config.http.insert_request_via_str then the problem goes away.
was:
We're seeing 400 Multi-Hop Cycle detected problems when
proxy.config.http.insert_request_via_str is enabled. We see the same problem on
both v4.0.2, v3.2.3 and v3.2.5.
The configuration we have that triggers this is:
{noformat}
map http://www.example.com/http://web1.example.net/
map https://api.example.com http://api1.example.net/
{noformat}
where web1.example.net is using mod_proxy to proxy some requests to
https://api.example.com:
{noformat}
SSLProxyEngine On
ProxyPass /api/menu https://api.example.com/test/api/menu
{noformat}
If www.example.com and api.example.com is going trough the same trafficserver
with proxy.config.http.insert_request_via_str enabled we get the Multi-Hop
Cycle detected error. If they are going trough different physical hosts, or if
we disable proxy.config.http.insert_request_via_str then the problem goes away.
Removed the https urls, as they weren't relevant..
400 Multi-Hop Cycle detected with .insert_request_via_str
-
Key: TS-2298
URL: https://issues.apache.org/jira/browse/TS-2298
Project: Traffic Server
Issue Type: Bug
Components: Core
Affects Versions: 3.2.5, 4.0.2
Environment: RHEL6, x86_64, apache httpd, mod_proxy
Reporter: Jan-Frode Myklebust
We're seeing 400 Multi-Hop Cycle detected problems when
proxy.config.http.insert_request_via_str is enabled. We see the same problem
on both v4.0.2, v3.2.3 and v3.2.5.
The configuration we have that triggers this is:
{noformat}
map http://www.example.com/http://web1.example.net/
map http://api.example.com http://api1.example.net/
{noformat}
where web1.example.net is using mod_proxy to proxy some requests to
http://api.example.com:
{noformat}
ProxyPass /api/menu http://api.example.com/test/api/menu
{noformat}
If www.example.com and api.example.com is going trough the same
trafficserver with proxy.config.http.insert_request_via_str enabled we get
the Multi-Hop Cycle detected error. If they are going trough different
physical hosts, or if we disable proxy.config.http.insert_request_via_str
then the problem goes away.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (TS-1125) POST's with Expect: 100-continue are slowed by delayed 100 response.
[ https://issues.apache.org/jira/browse/TS-1125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13610975#comment-13610975 ] Jan-Frode Myklebust commented on TS-1125: - Squid has a knob to ignore it: http://www.squid-cache.org/Doc/config/ignore_expect_100/ Wouldn't it be better to fake it -- provide a knob to return 100 continue regardless of if the backend will accept the request, than the current behaviour that doesn't return 100 continue before data is already posted ? POST's with Expect: 100-continue are slowed by delayed 100 response. Key: TS-1125 URL: https://issues.apache.org/jira/browse/TS-1125 Project: Traffic Server Issue Type: Bug Components: HTTP Affects Versions: 3.0.2 Environment: TS 3.0.2 going to Apache 2.2 web server Reporter: William Bardwell Priority: Minor Fix For: 3.3.3 Sending a post like: POST / HTTP/1.1 Host: www.example.com Content-Length: 10 Expect: 100-continue directly to the web server immediately sends back: HTTP/1.1 100 Continue And then when the post data is sent, a status 200 response comes back. But when going through ATS the HTTP/1.1 100 Continue is not sent immediately, and instead is sent after the POST data has been received. This is legal, but it makes clients that are hoping for a 100 continue to wait a little while hoping to get that, ATS should forward that response through immediately. Note: I see curl using Expect: 100-continue with 1024 bytes of post data, but web searching indicates that some Microsoft products also use it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1618) crash with 3.2.3
[
https://issues.apache.org/jira/browse/TS-1618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13530446#comment-13530446
]
Jan-Frode Myklebust commented on TS-1618:
-
This happened 3 times today...
$ dmesg
[ET_SSL 5][5644]: segfault at 50 ip 00628db7 sp 2b8407f80048 error
4 in traffic_server[40+34]
[ET_SSL 4][17737]: segfault at 50 ip 00628db7 sp 2ab0e7d56048 error
4 in traffic_server[40+34]
[ET_SSL 0][3799]: segfault at 50 ip 00628db7 sp 2b485b97a628 error
4 in traffic_server[40+34]
But every time it seemed to recover by restarting the segfaulted process.
Yesterday it didn't manage that, so we triggered a IP-address failover to
recover.
crash with 3.2.3
Key: TS-1618
URL: https://issues.apache.org/jira/browse/TS-1618
Project: Traffic Server
Issue Type: Bug
Affects Versions: 3.2.3
Reporter: Jan-Frode Myklebust
We're seeing crashes with 3.2.3 on RHEL6...
{noformat}
NOTE: Traffic Server received Sig 11: Segmentation fault
/usr/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0(+0xf500)[0x2b73de262500]
/usr/bin/traffic_server(CacheVC::is_pread_capable()+0x7)[0x628db7]
/usr/bin/traffic_server(HttpSM::do_range_setup_if_necessary()+0x1d0)[0x523270]
/usr/bin/traffic_server(HttpTransact::build_response_from_cache(HttpTransact::State*,
HTTPWarningCode)+0x242)[0x552672]
/usr/bin/traffic_server(HttpTransact::HandleCacheOpenReadHit(HttpTransact::State*)+0x4e1)[0x553711]
/usr/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void
(*)(HttpTransact::State*))+0x62)[0x51af92]
/usr/bin/traffic_server(HttpSM::handle_api_return()+0x31a)[0x534b8a]
/usr/bin/traffic_server(HttpSM::set_next_state()+0x18a)[0x5334ea]
/usr/bin/traffic_server(HttpSM::handle_api_return()+0x31a)[0x534b8a]
/usr/bin/traffic_server(HttpSM::set_next_state()+0x18a)[0x5334ea]
/usr/bin/traffic_server(HttpSM::state_cache_open_read(int,
void*)+0xfe)[0x5291be]
/usr/bin/traffic_server(HttpSM::main_handler(int, void*)+0xe8)[0x52b558]
/usr/bin/traffic_server(HttpCacheSM::state_cache_open_read(int,
void*)+0x1a2)[0x50a912]
/usr/bin/traffic_server(CacheVC::callcont(int)+0x27)[0x64af07]
/usr/bin/traffic_server(CacheVC::openReadStartHead(int,
Event*)+0x7e2)[0x646b42]
/usr/bin/traffic_server(Cache::open_read(Continuation*, INK_MD5*, HTTPHdr*,
CacheLookupHttpConfig*, CacheFragType, char*, int)+0x383)[0x647843]
/usr/bin/traffic_server(CacheProcessor::open_read(Continuation*, URL*,
HTTPHdr*, CacheLookupHttpConfig*, long, CacheFragType)+0x158)[0x624dd8]
/usr/bin/traffic_server(HttpCacheSM::open_read(URL*, HTTPHdr*,
CacheLookupHttpConfig*, long)+0x84)[0x50a364]
/usr/bin/traffic_server(HttpSM::do_cache_lookup_and_read()+0xf3)[0x51c263]
/usr/bin/traffic_server(HttpSM::set_next_state()+0x6d1)[0x533a31]
/usr/bin/traffic_server(HttpSM::handle_api_return()+0x31a)[0x534b8a]
/usr/bin/traffic_server(HttpSM::set_next_state()+0x18a)[0x5334ea]
/usr/bin/traffic_server(HttpSM::set_next_state()+0x7c4)[0x533b24]
/usr/bin/traffic_server(HttpSM::handle_api_return()+0x31a)[0x534b8a]
/usr/bin/traffic_server(HttpSM::set_next_state()+0x18a)[0x5334ea]
/usr/bin/traffic_server(HttpSM::handle_api_return()+0x31a)[0x534b8a]
/usr/bin/traffic_server(HttpSM::set_next_state()+0x18a)[0x5334ea]
/usr/bin/traffic_server(HttpSM::state_read_client_request_header(int,
void*)+0x6b7)[0x52d527]
/usr/bin/traffic_server(HttpSM::main_handler(int, void*)+0xe8)[0x52b558]
/usr/bin/traffic_server(UnixNetVConnection::readSignalAndUpdate(int)+0x27)[0x6724a7]
/usr/bin/traffic_server(SSLNetVConnection::net_read_io(NetHandler*,
EThread*)+0x832)[0x666bc2]
/usr/bin/traffic_server(NetHandler::mainNetEvent(int, Event*)+0x1f2)[0x66da12]
/usr/bin/traffic_server(EThread::process_event(Event*, int)+0xb4)[0x6966e4]
/usr/bin/traffic_server(EThread::execute()+0x4c3)[0x697073]
/usr/bin/traffic_server[0x6956b2]
/lib64/libpthread.so.0(+0x7851)[0x2b73de25a851]
/lib64/libc.so.6(clone+0x6d)[0x2b73e06e467d]
[Dec 11 15:55:04.099] Manager {0x7f2ef4f7d7e0} FATAL:
[LocalManager::pollMgmtProcessServer] Error in read (errno: 104)
[Dec 11 15:55:04.099] Manager {0x7f2ef4f7d7e0} FATAL: (last system error
104: Connection reset by peer)
[Dec 11 15:55:04.099] Manager {0x7f2ef4f7d7e0} NOTE:
[LocalManager::mgmtShutdown] Executing shutdown request.
[Dec 11 15:55:04.099] Manager {0x7f2ef4f7d7e0} NOTE:
[LocalManager::processShutdown] Executing process shutdown request.
[Dec 11 15:55:04.100] Manager {0x7f2ef4f7d7e0} ERROR:
[LocalManager::sendMgmtMsgToProcesses] Error writing message
[Dec 11 15:55:04.100] Manager {0x7f2ef4f7d7e0} ERROR: (last system error 32:
Broken pipe)
{noformat}
Please let me know if there's anything else I can provide to debug this.
--
This message is automatically generated by JIRA.
[jira] [Commented] (TS-1618) crash with 3.2.3
[
https://issues.apache.org/jira/browse/TS-1618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13530471#comment-13530471
]
Jan-Frode Myklebust commented on TS-1618:
-
Is this a duplicate of TS-1377 ?
crash with 3.2.3
Key: TS-1618
URL: https://issues.apache.org/jira/browse/TS-1618
Project: Traffic Server
Issue Type: Bug
Affects Versions: 3.2.3
Reporter: Jan-Frode Myklebust
We're seeing crashes with 3.2.3 on RHEL6...
{noformat}
NOTE: Traffic Server received Sig 11: Segmentation fault
/usr/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0(+0xf500)[0x2b73de262500]
/usr/bin/traffic_server(CacheVC::is_pread_capable()+0x7)[0x628db7]
/usr/bin/traffic_server(HttpSM::do_range_setup_if_necessary()+0x1d0)[0x523270]
/usr/bin/traffic_server(HttpTransact::build_response_from_cache(HttpTransact::State*,
HTTPWarningCode)+0x242)[0x552672]
/usr/bin/traffic_server(HttpTransact::HandleCacheOpenReadHit(HttpTransact::State*)+0x4e1)[0x553711]
/usr/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void
(*)(HttpTransact::State*))+0x62)[0x51af92]
/usr/bin/traffic_server(HttpSM::handle_api_return()+0x31a)[0x534b8a]
/usr/bin/traffic_server(HttpSM::set_next_state()+0x18a)[0x5334ea]
/usr/bin/traffic_server(HttpSM::handle_api_return()+0x31a)[0x534b8a]
/usr/bin/traffic_server(HttpSM::set_next_state()+0x18a)[0x5334ea]
/usr/bin/traffic_server(HttpSM::state_cache_open_read(int,
void*)+0xfe)[0x5291be]
/usr/bin/traffic_server(HttpSM::main_handler(int, void*)+0xe8)[0x52b558]
/usr/bin/traffic_server(HttpCacheSM::state_cache_open_read(int,
void*)+0x1a2)[0x50a912]
/usr/bin/traffic_server(CacheVC::callcont(int)+0x27)[0x64af07]
/usr/bin/traffic_server(CacheVC::openReadStartHead(int,
Event*)+0x7e2)[0x646b42]
/usr/bin/traffic_server(Cache::open_read(Continuation*, INK_MD5*, HTTPHdr*,
CacheLookupHttpConfig*, CacheFragType, char*, int)+0x383)[0x647843]
/usr/bin/traffic_server(CacheProcessor::open_read(Continuation*, URL*,
HTTPHdr*, CacheLookupHttpConfig*, long, CacheFragType)+0x158)[0x624dd8]
/usr/bin/traffic_server(HttpCacheSM::open_read(URL*, HTTPHdr*,
CacheLookupHttpConfig*, long)+0x84)[0x50a364]
/usr/bin/traffic_server(HttpSM::do_cache_lookup_and_read()+0xf3)[0x51c263]
/usr/bin/traffic_server(HttpSM::set_next_state()+0x6d1)[0x533a31]
/usr/bin/traffic_server(HttpSM::handle_api_return()+0x31a)[0x534b8a]
/usr/bin/traffic_server(HttpSM::set_next_state()+0x18a)[0x5334ea]
/usr/bin/traffic_server(HttpSM::set_next_state()+0x7c4)[0x533b24]
/usr/bin/traffic_server(HttpSM::handle_api_return()+0x31a)[0x534b8a]
/usr/bin/traffic_server(HttpSM::set_next_state()+0x18a)[0x5334ea]
/usr/bin/traffic_server(HttpSM::handle_api_return()+0x31a)[0x534b8a]
/usr/bin/traffic_server(HttpSM::set_next_state()+0x18a)[0x5334ea]
/usr/bin/traffic_server(HttpSM::state_read_client_request_header(int,
void*)+0x6b7)[0x52d527]
/usr/bin/traffic_server(HttpSM::main_handler(int, void*)+0xe8)[0x52b558]
/usr/bin/traffic_server(UnixNetVConnection::readSignalAndUpdate(int)+0x27)[0x6724a7]
/usr/bin/traffic_server(SSLNetVConnection::net_read_io(NetHandler*,
EThread*)+0x832)[0x666bc2]
/usr/bin/traffic_server(NetHandler::mainNetEvent(int, Event*)+0x1f2)[0x66da12]
/usr/bin/traffic_server(EThread::process_event(Event*, int)+0xb4)[0x6966e4]
/usr/bin/traffic_server(EThread::execute()+0x4c3)[0x697073]
/usr/bin/traffic_server[0x6956b2]
/lib64/libpthread.so.0(+0x7851)[0x2b73de25a851]
/lib64/libc.so.6(clone+0x6d)[0x2b73e06e467d]
[Dec 11 15:55:04.099] Manager {0x7f2ef4f7d7e0} FATAL:
[LocalManager::pollMgmtProcessServer] Error in read (errno: 104)
[Dec 11 15:55:04.099] Manager {0x7f2ef4f7d7e0} FATAL: (last system error
104: Connection reset by peer)
[Dec 11 15:55:04.099] Manager {0x7f2ef4f7d7e0} NOTE:
[LocalManager::mgmtShutdown] Executing shutdown request.
[Dec 11 15:55:04.099] Manager {0x7f2ef4f7d7e0} NOTE:
[LocalManager::processShutdown] Executing process shutdown request.
[Dec 11 15:55:04.100] Manager {0x7f2ef4f7d7e0} ERROR:
[LocalManager::sendMgmtMsgToProcesses] Error writing message
[Dec 11 15:55:04.100] Manager {0x7f2ef4f7d7e0} ERROR: (last system error 32:
Broken pipe)
{noformat}
Please let me know if there's anything else I can provide to debug this.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-1618) crash with 3.2.3
Jan-Frode Myklebust created TS-1618:
---
Summary: crash with 3.2.3
Key: TS-1618
URL: https://issues.apache.org/jira/browse/TS-1618
Project: Traffic Server
Issue Type: Bug
Reporter: Jan-Frode Myklebust
We're seeing crashes with 3.2.3 on RHEL6...
NOTE: Traffic Server received Sig 11: Segmentation fault
/usr/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0(+0xf500)[0x2b73de262500]
/usr/bin/traffic_server(_ZN7CacheVC16is_pread_capableEv+0x7)[0x628db7]
/usr/bin/traffic_server(_ZN6HttpSM27do_range_setup_if_necessaryEv+0x1d0)[0x523270]
/usr/bin/traffic_server(_ZN12HttpTransact25build_response_from_cacheEPNS_5StateE15HTTPWarningCode+0x242)[0x552672]
/usr/bin/traffic_server(_ZN12HttpTransact22HandleCacheOpenReadHitEPNS_5StateE+0x4e1)[0x553711]
/usr/bin/traffic_server(_ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE+0x62)[0x51af92]
/usr/bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x31a)[0x534b8a]
/usr/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x18a)[0x5334ea]
/usr/bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x31a)[0x534b8a]
/usr/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x18a)[0x5334ea]
/usr/bin/traffic_server(_ZN6HttpSM21state_cache_open_readEiPv+0xfe)[0x5291be]
/usr/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0xe8)[0x52b558]
/usr/bin/traffic_server(_ZN11HttpCacheSM21state_cache_open_readEiPv+0x1a2)[0x50a912]
/usr/bin/traffic_server(_ZN7CacheVC8callcontEi+0x27)[0x64af07]
/usr/bin/traffic_server(_ZN7CacheVC17openReadStartHeadEiP5Event+0x7e2)[0x646b42]
/usr/bin/traffic_server(_ZN5Cache9open_readEP12ContinuationP7INK_MD5P7HTTPHdrP21CacheLookupHttpConfig13CacheFragTypePci+0x383)[0x647843]
/usr/bin/traffic_server(_ZN14CacheProcessor9open_readEP12ContinuationP3URLP7HTTPHdrP21CacheLookupHttpConfigl13CacheFragType+0x158)[0x624dd8]
/usr/bin/traffic_server(_ZN11HttpCacheSM9open_readEP3URLP7HTTPHdrP21CacheLookupHttpConfigl+0x84)[0x50a364]
/usr/bin/traffic_server(_ZN6HttpSM24do_cache_lookup_and_readEv+0xf3)[0x51c263]
/usr/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x6d1)[0x533a31]
/usr/bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x31a)[0x534b8a]
/usr/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x18a)[0x5334ea]
/usr/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x7c4)[0x533b24]
/usr/bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x31a)[0x534b8a]
/usr/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x18a)[0x5334ea]
/usr/bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x31a)[0x534b8a]
/usr/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x18a)[0x5334ea]
/usr/bin/traffic_server(_ZN6HttpSM32state_read_client_request_headerEiPv+0x6b7)[0x52d527]
/usr/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0xe8)[0x52b558]
/usr/bin/traffic_server(_ZN18UnixNetVConnection19readSignalAndUpdateEi+0x27)[0x6724a7]
/usr/bin/traffic_server(_ZN17SSLNetVConnection11net_read_ioEP10NetHandlerP7EThread+0x832)[0x666bc2]
/usr/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x1f2)[0x66da12]
/usr/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0xb4)[0x6966e4]
/usr/bin/traffic_server(_ZN7EThread7executeEv+0x4c3)[0x697073]
/usr/bin/traffic_server[0x6956b2]
/lib64/libpthread.so.0(+0x7851)[0x2b73de25a851]
/lib64/libc.so.6(clone+0x6d)[0x2b73e06e467d]
[Dec 11 15:55:04.099] Manager {0x7f2ef4f7d7e0} FATAL:
[LocalManager::pollMgmtProcessServer] Error in read (errno: 104)
[Dec 11 15:55:04.099] Manager {0x7f2ef4f7d7e0} FATAL: (last system error 104:
Connection reset by peer)
[Dec 11 15:55:04.099] Manager {0x7f2ef4f7d7e0} NOTE:
[LocalManager::mgmtShutdown] Executing shutdown request.
[Dec 11 15:55:04.099] Manager {0x7f2ef4f7d7e0} NOTE:
[LocalManager::processShutdown] Executing process shutdown request.
[Dec 11 15:55:04.100] Manager {0x7f2ef4f7d7e0} ERROR:
[LocalManager::sendMgmtMsgToProcesses] Error writing message
[Dec 11 15:55:04.100] Manager {0x7f2ef4f7d7e0} ERROR: (last system error 32:
Broken pipe)
Please let me know if there's anything else I can provide to debug this.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1618) crash with 3.2.3
[
https://issues.apache.org/jira/browse/TS-1618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13529287#comment-13529287
]
Jan-Frode Myklebust commented on TS-1618:
-
RHEL6, x86_64, using IPv4 and IPv6, using multiple wildcard SSL certificates,
running on RHEV virtual machines, no clustering (do IP address failover outside
of ATS), running as reverse proxy.
crash with 3.2.3
Key: TS-1618
URL: https://issues.apache.org/jira/browse/TS-1618
Project: Traffic Server
Issue Type: Bug
Reporter: Jan-Frode Myklebust
We're seeing crashes with 3.2.3 on RHEL6...
{noformat}
NOTE: Traffic Server received Sig 11: Segmentation fault
/usr/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0(+0xf500)[0x2b73de262500]
/usr/bin/traffic_server(CacheVC::is_pread_capable()+0x7)[0x628db7]
/usr/bin/traffic_server(HttpSM::do_range_setup_if_necessary()+0x1d0)[0x523270]
/usr/bin/traffic_server(HttpTransact::build_response_from_cache(HttpTransact::State*,
HTTPWarningCode)+0x242)[0x552672]
/usr/bin/traffic_server(HttpTransact::HandleCacheOpenReadHit(HttpTransact::State*)+0x4e1)[0x553711]
/usr/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void
(*)(HttpTransact::State*))+0x62)[0x51af92]
/usr/bin/traffic_server(HttpSM::handle_api_return()+0x31a)[0x534b8a]
/usr/bin/traffic_server(HttpSM::set_next_state()+0x18a)[0x5334ea]
/usr/bin/traffic_server(HttpSM::handle_api_return()+0x31a)[0x534b8a]
/usr/bin/traffic_server(HttpSM::set_next_state()+0x18a)[0x5334ea]
/usr/bin/traffic_server(HttpSM::state_cache_open_read(int,
void*)+0xfe)[0x5291be]
/usr/bin/traffic_server(HttpSM::main_handler(int, void*)+0xe8)[0x52b558]
/usr/bin/traffic_server(HttpCacheSM::state_cache_open_read(int,
void*)+0x1a2)[0x50a912]
/usr/bin/traffic_server(CacheVC::callcont(int)+0x27)[0x64af07]
/usr/bin/traffic_server(CacheVC::openReadStartHead(int,
Event*)+0x7e2)[0x646b42]
/usr/bin/traffic_server(Cache::open_read(Continuation*, INK_MD5*, HTTPHdr*,
CacheLookupHttpConfig*, CacheFragType, char*, int)+0x383)[0x647843]
/usr/bin/traffic_server(CacheProcessor::open_read(Continuation*, URL*,
HTTPHdr*, CacheLookupHttpConfig*, long, CacheFragType)+0x158)[0x624dd8]
/usr/bin/traffic_server(HttpCacheSM::open_read(URL*, HTTPHdr*,
CacheLookupHttpConfig*, long)+0x84)[0x50a364]
/usr/bin/traffic_server(HttpSM::do_cache_lookup_and_read()+0xf3)[0x51c263]
/usr/bin/traffic_server(HttpSM::set_next_state()+0x6d1)[0x533a31]
/usr/bin/traffic_server(HttpSM::handle_api_return()+0x31a)[0x534b8a]
/usr/bin/traffic_server(HttpSM::set_next_state()+0x18a)[0x5334ea]
/usr/bin/traffic_server(HttpSM::set_next_state()+0x7c4)[0x533b24]
/usr/bin/traffic_server(HttpSM::handle_api_return()+0x31a)[0x534b8a]
/usr/bin/traffic_server(HttpSM::set_next_state()+0x18a)[0x5334ea]
/usr/bin/traffic_server(HttpSM::handle_api_return()+0x31a)[0x534b8a]
/usr/bin/traffic_server(HttpSM::set_next_state()+0x18a)[0x5334ea]
/usr/bin/traffic_server(HttpSM::state_read_client_request_header(int,
void*)+0x6b7)[0x52d527]
/usr/bin/traffic_server(HttpSM::main_handler(int, void*)+0xe8)[0x52b558]
/usr/bin/traffic_server(UnixNetVConnection::readSignalAndUpdate(int)+0x27)[0x6724a7]
/usr/bin/traffic_server(SSLNetVConnection::net_read_io(NetHandler*,
EThread*)+0x832)[0x666bc2]
/usr/bin/traffic_server(NetHandler::mainNetEvent(int, Event*)+0x1f2)[0x66da12]
/usr/bin/traffic_server(EThread::process_event(Event*, int)+0xb4)[0x6966e4]
/usr/bin/traffic_server(EThread::execute()+0x4c3)[0x697073]
/usr/bin/traffic_server[0x6956b2]
/lib64/libpthread.so.0(+0x7851)[0x2b73de25a851]
/lib64/libc.so.6(clone+0x6d)[0x2b73e06e467d]
[Dec 11 15:55:04.099] Manager {0x7f2ef4f7d7e0} FATAL:
[LocalManager::pollMgmtProcessServer] Error in read (errno: 104)
[Dec 11 15:55:04.099] Manager {0x7f2ef4f7d7e0} FATAL: (last system error
104: Connection reset by peer)
[Dec 11 15:55:04.099] Manager {0x7f2ef4f7d7e0} NOTE:
[LocalManager::mgmtShutdown] Executing shutdown request.
[Dec 11 15:55:04.099] Manager {0x7f2ef4f7d7e0} NOTE:
[LocalManager::processShutdown] Executing process shutdown request.
[Dec 11 15:55:04.100] Manager {0x7f2ef4f7d7e0} ERROR:
[LocalManager::sendMgmtMsgToProcesses] Error writing message
[Dec 11 15:55:04.100] Manager {0x7f2ef4f7d7e0} ERROR: (last system error 32:
Broken pipe)
{noformat}
Please let me know if there's anything else I can provide to debug this.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1618) crash with 3.2.3
[
https://issues.apache.org/jira/browse/TS-1618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13529321#comment-13529321
]
Jan-Frode Myklebust commented on TS-1618:
-
The ATS version is trafficserver-3.2.3.tar.bz2
(313b7c6e8303bb21e93a9c3e0c33d170) as announced in:
http://mail-archives.apache.org/mod_mbox/trafficserver-users/201210.mbox/%3c1949983350.127675.1350122656277.javamail.r...@brainsware.org%3e
Plus the patch for TS-1526.
crash with 3.2.3
Key: TS-1618
URL: https://issues.apache.org/jira/browse/TS-1618
Project: Traffic Server
Issue Type: Bug
Reporter: Jan-Frode Myklebust
We're seeing crashes with 3.2.3 on RHEL6...
{noformat}
NOTE: Traffic Server received Sig 11: Segmentation fault
/usr/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0(+0xf500)[0x2b73de262500]
/usr/bin/traffic_server(CacheVC::is_pread_capable()+0x7)[0x628db7]
/usr/bin/traffic_server(HttpSM::do_range_setup_if_necessary()+0x1d0)[0x523270]
/usr/bin/traffic_server(HttpTransact::build_response_from_cache(HttpTransact::State*,
HTTPWarningCode)+0x242)[0x552672]
/usr/bin/traffic_server(HttpTransact::HandleCacheOpenReadHit(HttpTransact::State*)+0x4e1)[0x553711]
/usr/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void
(*)(HttpTransact::State*))+0x62)[0x51af92]
/usr/bin/traffic_server(HttpSM::handle_api_return()+0x31a)[0x534b8a]
/usr/bin/traffic_server(HttpSM::set_next_state()+0x18a)[0x5334ea]
/usr/bin/traffic_server(HttpSM::handle_api_return()+0x31a)[0x534b8a]
/usr/bin/traffic_server(HttpSM::set_next_state()+0x18a)[0x5334ea]
/usr/bin/traffic_server(HttpSM::state_cache_open_read(int,
void*)+0xfe)[0x5291be]
/usr/bin/traffic_server(HttpSM::main_handler(int, void*)+0xe8)[0x52b558]
/usr/bin/traffic_server(HttpCacheSM::state_cache_open_read(int,
void*)+0x1a2)[0x50a912]
/usr/bin/traffic_server(CacheVC::callcont(int)+0x27)[0x64af07]
/usr/bin/traffic_server(CacheVC::openReadStartHead(int,
Event*)+0x7e2)[0x646b42]
/usr/bin/traffic_server(Cache::open_read(Continuation*, INK_MD5*, HTTPHdr*,
CacheLookupHttpConfig*, CacheFragType, char*, int)+0x383)[0x647843]
/usr/bin/traffic_server(CacheProcessor::open_read(Continuation*, URL*,
HTTPHdr*, CacheLookupHttpConfig*, long, CacheFragType)+0x158)[0x624dd8]
/usr/bin/traffic_server(HttpCacheSM::open_read(URL*, HTTPHdr*,
CacheLookupHttpConfig*, long)+0x84)[0x50a364]
/usr/bin/traffic_server(HttpSM::do_cache_lookup_and_read()+0xf3)[0x51c263]
/usr/bin/traffic_server(HttpSM::set_next_state()+0x6d1)[0x533a31]
/usr/bin/traffic_server(HttpSM::handle_api_return()+0x31a)[0x534b8a]
/usr/bin/traffic_server(HttpSM::set_next_state()+0x18a)[0x5334ea]
/usr/bin/traffic_server(HttpSM::set_next_state()+0x7c4)[0x533b24]
/usr/bin/traffic_server(HttpSM::handle_api_return()+0x31a)[0x534b8a]
/usr/bin/traffic_server(HttpSM::set_next_state()+0x18a)[0x5334ea]
/usr/bin/traffic_server(HttpSM::handle_api_return()+0x31a)[0x534b8a]
/usr/bin/traffic_server(HttpSM::set_next_state()+0x18a)[0x5334ea]
/usr/bin/traffic_server(HttpSM::state_read_client_request_header(int,
void*)+0x6b7)[0x52d527]
/usr/bin/traffic_server(HttpSM::main_handler(int, void*)+0xe8)[0x52b558]
/usr/bin/traffic_server(UnixNetVConnection::readSignalAndUpdate(int)+0x27)[0x6724a7]
/usr/bin/traffic_server(SSLNetVConnection::net_read_io(NetHandler*,
EThread*)+0x832)[0x666bc2]
/usr/bin/traffic_server(NetHandler::mainNetEvent(int, Event*)+0x1f2)[0x66da12]
/usr/bin/traffic_server(EThread::process_event(Event*, int)+0xb4)[0x6966e4]
/usr/bin/traffic_server(EThread::execute()+0x4c3)[0x697073]
/usr/bin/traffic_server[0x6956b2]
/lib64/libpthread.so.0(+0x7851)[0x2b73de25a851]
/lib64/libc.so.6(clone+0x6d)[0x2b73e06e467d]
[Dec 11 15:55:04.099] Manager {0x7f2ef4f7d7e0} FATAL:
[LocalManager::pollMgmtProcessServer] Error in read (errno: 104)
[Dec 11 15:55:04.099] Manager {0x7f2ef4f7d7e0} FATAL: (last system error
104: Connection reset by peer)
[Dec 11 15:55:04.099] Manager {0x7f2ef4f7d7e0} NOTE:
[LocalManager::mgmtShutdown] Executing shutdown request.
[Dec 11 15:55:04.099] Manager {0x7f2ef4f7d7e0} NOTE:
[LocalManager::processShutdown] Executing process shutdown request.
[Dec 11 15:55:04.100] Manager {0x7f2ef4f7d7e0} ERROR:
[LocalManager::sendMgmtMsgToProcesses] Error writing message
[Dec 11 15:55:04.100] Manager {0x7f2ef4f7d7e0} ERROR: (last system error 32:
Broken pipe)
{noformat}
Please let me know if there's anything else I can provide to debug this.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1618) crash with 3.2.3
[
https://issues.apache.org/jira/browse/TS-1618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan-Frode Myklebust updated TS-1618:
Affects Version/s: 3.2.3
crash with 3.2.3
Key: TS-1618
URL: https://issues.apache.org/jira/browse/TS-1618
Project: Traffic Server
Issue Type: Bug
Affects Versions: 3.2.3
Reporter: Jan-Frode Myklebust
We're seeing crashes with 3.2.3 on RHEL6...
{noformat}
NOTE: Traffic Server received Sig 11: Segmentation fault
/usr/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0(+0xf500)[0x2b73de262500]
/usr/bin/traffic_server(CacheVC::is_pread_capable()+0x7)[0x628db7]
/usr/bin/traffic_server(HttpSM::do_range_setup_if_necessary()+0x1d0)[0x523270]
/usr/bin/traffic_server(HttpTransact::build_response_from_cache(HttpTransact::State*,
HTTPWarningCode)+0x242)[0x552672]
/usr/bin/traffic_server(HttpTransact::HandleCacheOpenReadHit(HttpTransact::State*)+0x4e1)[0x553711]
/usr/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void
(*)(HttpTransact::State*))+0x62)[0x51af92]
/usr/bin/traffic_server(HttpSM::handle_api_return()+0x31a)[0x534b8a]
/usr/bin/traffic_server(HttpSM::set_next_state()+0x18a)[0x5334ea]
/usr/bin/traffic_server(HttpSM::handle_api_return()+0x31a)[0x534b8a]
/usr/bin/traffic_server(HttpSM::set_next_state()+0x18a)[0x5334ea]
/usr/bin/traffic_server(HttpSM::state_cache_open_read(int,
void*)+0xfe)[0x5291be]
/usr/bin/traffic_server(HttpSM::main_handler(int, void*)+0xe8)[0x52b558]
/usr/bin/traffic_server(HttpCacheSM::state_cache_open_read(int,
void*)+0x1a2)[0x50a912]
/usr/bin/traffic_server(CacheVC::callcont(int)+0x27)[0x64af07]
/usr/bin/traffic_server(CacheVC::openReadStartHead(int,
Event*)+0x7e2)[0x646b42]
/usr/bin/traffic_server(Cache::open_read(Continuation*, INK_MD5*, HTTPHdr*,
CacheLookupHttpConfig*, CacheFragType, char*, int)+0x383)[0x647843]
/usr/bin/traffic_server(CacheProcessor::open_read(Continuation*, URL*,
HTTPHdr*, CacheLookupHttpConfig*, long, CacheFragType)+0x158)[0x624dd8]
/usr/bin/traffic_server(HttpCacheSM::open_read(URL*, HTTPHdr*,
CacheLookupHttpConfig*, long)+0x84)[0x50a364]
/usr/bin/traffic_server(HttpSM::do_cache_lookup_and_read()+0xf3)[0x51c263]
/usr/bin/traffic_server(HttpSM::set_next_state()+0x6d1)[0x533a31]
/usr/bin/traffic_server(HttpSM::handle_api_return()+0x31a)[0x534b8a]
/usr/bin/traffic_server(HttpSM::set_next_state()+0x18a)[0x5334ea]
/usr/bin/traffic_server(HttpSM::set_next_state()+0x7c4)[0x533b24]
/usr/bin/traffic_server(HttpSM::handle_api_return()+0x31a)[0x534b8a]
/usr/bin/traffic_server(HttpSM::set_next_state()+0x18a)[0x5334ea]
/usr/bin/traffic_server(HttpSM::handle_api_return()+0x31a)[0x534b8a]
/usr/bin/traffic_server(HttpSM::set_next_state()+0x18a)[0x5334ea]
/usr/bin/traffic_server(HttpSM::state_read_client_request_header(int,
void*)+0x6b7)[0x52d527]
/usr/bin/traffic_server(HttpSM::main_handler(int, void*)+0xe8)[0x52b558]
/usr/bin/traffic_server(UnixNetVConnection::readSignalAndUpdate(int)+0x27)[0x6724a7]
/usr/bin/traffic_server(SSLNetVConnection::net_read_io(NetHandler*,
EThread*)+0x832)[0x666bc2]
/usr/bin/traffic_server(NetHandler::mainNetEvent(int, Event*)+0x1f2)[0x66da12]
/usr/bin/traffic_server(EThread::process_event(Event*, int)+0xb4)[0x6966e4]
/usr/bin/traffic_server(EThread::execute()+0x4c3)[0x697073]
/usr/bin/traffic_server[0x6956b2]
/lib64/libpthread.so.0(+0x7851)[0x2b73de25a851]
/lib64/libc.so.6(clone+0x6d)[0x2b73e06e467d]
[Dec 11 15:55:04.099] Manager {0x7f2ef4f7d7e0} FATAL:
[LocalManager::pollMgmtProcessServer] Error in read (errno: 104)
[Dec 11 15:55:04.099] Manager {0x7f2ef4f7d7e0} FATAL: (last system error
104: Connection reset by peer)
[Dec 11 15:55:04.099] Manager {0x7f2ef4f7d7e0} NOTE:
[LocalManager::mgmtShutdown] Executing shutdown request.
[Dec 11 15:55:04.099] Manager {0x7f2ef4f7d7e0} NOTE:
[LocalManager::processShutdown] Executing process shutdown request.
[Dec 11 15:55:04.100] Manager {0x7f2ef4f7d7e0} ERROR:
[LocalManager::sendMgmtMsgToProcesses] Error writing message
[Dec 11 15:55:04.100] Manager {0x7f2ef4f7d7e0} ERROR: (last system error 32:
Broken pipe)
{noformat}
Please let me know if there's anything else I can provide to debug this.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1125) POST's with Expect: 100-continue are slowed by delayed 100 response.
[ https://issues.apache.org/jira/browse/TS-1125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13507359#comment-13507359 ] Jan-Frode Myklebust commented on TS-1125: - It seems to be waiting more than a little while. We see a full 2 second delay for POST with large responses from origin server, on ATS 3.2.3. POST's with Expect: 100-continue are slowed by delayed 100 response. Key: TS-1125 URL: https://issues.apache.org/jira/browse/TS-1125 Project: Traffic Server Issue Type: Bug Components: HTTP Affects Versions: 3.0.2 Environment: TS 3.0.2 going to Apache 2.2 web server Reporter: William Bardwell Priority: Minor Fix For: 3.3.1 Sending a post like: POST / HTTP/1.1 Host: www.example.com Content-Length: 10 Expect: 100-continue directly to the web server immediately sends back: HTTP/1.1 100 Continue And then when the post data is sent, a status 200 response comes back. But when going through ATS the HTTP/1.1 100 Continue is not sent immediately, and instead is sent after the POST data has been received. This is legal, but it makes clients that are hoping for a 100 continue to wait a little while hoping to get that, ATS should forward that response through immediately. Note: I see curl using Expect: 100-continue with 1024 bytes of post data, but web searching indicates that some Microsoft products also use it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1484) SSL-crashed every now and then with 3.2.0 + SNI-fixes
[
https://issues.apache.org/jira/browse/TS-1484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13460418#comment-13460418
]
Jan-Frode Myklebust commented on TS-1484:
-
Oh.. but it was working perfectly so far.
Could you please help me with a version for 3.2.0 or preferably 3.2.0 + TS-1392
(9c3bebd88eecf6aee1ce346b67460b8e1787752d)? It doesn't quite apply to either of
these...
SSL-crashed every now and then with 3.2.0 + SNI-fixes
-
Key: TS-1484
URL: https://issues.apache.org/jira/browse/TS-1484
Project: Traffic Server
Issue Type: Bug
Components: SSL
Affects Versions: 3.2.0
Environment: RHEL6, x86_64, RHEV Virtual machines, IPv4 and IPv6
failover addresses, wildcard SSL-certificates
Reporter: Jan-Frode Myklebust
Assignee: James Peach
Attachments: TS1484.patch
We're running ATS v3.2.0 + patch 9c3bebd88eecf6aee1ce346b67460b8e1787752d to
fix support for non-SNI browsers, and every now and (daily I think) then
we're getting this crash:
[Sep 19 03:14:00.147] Server {0x2b2517a7c700} ERROR: SSL ERROR:
SSL_ServerHandShake.
[Sep 19 03:14:00.148] Server {0x2b2517a7c700} ERROR:
SSL::8:error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown
protocol:s23_srvr.c:593:
NOTE: Traffic Server received Sig 11: Segmentation fault
/usr/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0(+0xf500)[0x2b2505b84500]
/usr/lib64/libssl.so.10(SSL_CTX_callback_ctrl+0x5)[0x2b250662f425]
/usr/bin/traffic_server(_ZN17SSLNetVConnection17sslStartHandShakeEiRi+0xf2)[0x6675a2]
/usr/bin/traffic_server(_ZN17SSLNetVConnection11net_read_ioEP10NetHandlerP7EThread+0x208)[0x666c78]
/usr/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x1f2)[0x66e0e2]
/usr/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0xb4)[0x696c94]
/usr/bin/traffic_server(_ZN7EThread7executeEv+0x4c3)[0x697623]
/usr/bin/traffic_server[0x695c62]
/lib64/libpthread.so.0(+0x7851)[0x2b2505b7c851]
/lib64/libc.so.6(clone+0x6d)[0x2b250800667d]
[Sep 19 03:14:00.159] Manager {0x7ff63f1b07e0} ERROR:
[LocalManager::pollMgmtProcessServer] Server Process terminated due to Sig
11: Segmentation fault
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1484) SSL-crashed every now and then with 3.2.0 + SNI-fixes
[
https://issues.apache.org/jira/browse/TS-1484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13459488#comment-13459488
]
Jan-Frode Myklebust commented on TS-1484:
-
Thanks! I've applied your patch on 4 servers where we were experiencing this
problem. Will let you know if it works or not..
SSL-crashed every now and then with 3.2.0 + SNI-fixes
-
Key: TS-1484
URL: https://issues.apache.org/jira/browse/TS-1484
Project: Traffic Server
Issue Type: Bug
Components: SSL
Affects Versions: 3.2.0
Environment: RHEL6, x86_64, RHEV Virtual machines, IPv4 and IPv6
failover addresses, wildcard SSL-certificates
Reporter: Jan-Frode Myklebust
Assignee: James Peach
Attachments: TS1484.patch
We're running ATS v3.2.0 + patch 9c3bebd88eecf6aee1ce346b67460b8e1787752d to
fix support for non-SNI browsers, and every now and (daily I think) then
we're getting this crash:
[Sep 19 03:14:00.147] Server {0x2b2517a7c700} ERROR: SSL ERROR:
SSL_ServerHandShake.
[Sep 19 03:14:00.148] Server {0x2b2517a7c700} ERROR:
SSL::8:error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown
protocol:s23_srvr.c:593:
NOTE: Traffic Server received Sig 11: Segmentation fault
/usr/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0(+0xf500)[0x2b2505b84500]
/usr/lib64/libssl.so.10(SSL_CTX_callback_ctrl+0x5)[0x2b250662f425]
/usr/bin/traffic_server(_ZN17SSLNetVConnection17sslStartHandShakeEiRi+0xf2)[0x6675a2]
/usr/bin/traffic_server(_ZN17SSLNetVConnection11net_read_ioEP10NetHandlerP7EThread+0x208)[0x666c78]
/usr/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x1f2)[0x66e0e2]
/usr/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0xb4)[0x696c94]
/usr/bin/traffic_server(_ZN7EThread7executeEv+0x4c3)[0x697623]
/usr/bin/traffic_server[0x695c62]
/lib64/libpthread.so.0(+0x7851)[0x2b2505b7c851]
/lib64/libc.so.6(clone+0x6d)[0x2b250800667d]
[Sep 19 03:14:00.159] Manager {0x7ff63f1b07e0} ERROR:
[LocalManager::pollMgmtProcessServer] Server Process terminated due to Sig
11: Segmentation fault
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-1484) SSL-crashed every now and then with 3.2.0 + SNI-fixes
Jan-Frode Myklebust created TS-1484:
---
Summary: SSL-crashed every now and then with 3.2.0 + SNI-fixes
Key: TS-1484
URL: https://issues.apache.org/jira/browse/TS-1484
Project: Traffic Server
Issue Type: Bug
Components: SSL
Affects Versions: 3.2.0
Environment: RHEL6, x86_64, RHEV Virtual machines, IPv4 and IPv6
failover addresses, wildcard SSL-certificates
Reporter: Jan-Frode Myklebust
We're running ATS v3.2.0 + patch 9c3bebd88eecf6aee1ce346b67460b8e1787752d to
fix support for non-SNI browsers, and every now and (daily I think) then we're
getting this crash:
[Sep 19 03:14:00.147] Server {0x2b2517a7c700} ERROR: SSL ERROR:
SSL_ServerHandShake.
[Sep 19 03:14:00.148] Server {0x2b2517a7c700} ERROR: SSL::8:error:140760FC:SSL
routines:SSL23_GET_CLIENT_HELLO:unknown protocol:s23_srvr.c:593:
NOTE: Traffic Server received Sig 11: Segmentation fault
/usr/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0(+0xf500)[0x2b2505b84500]
/usr/lib64/libssl.so.10(SSL_CTX_callback_ctrl+0x5)[0x2b250662f425]
/usr/bin/traffic_server(_ZN17SSLNetVConnection17sslStartHandShakeEiRi+0xf2)[0x6675a2]
/usr/bin/traffic_server(_ZN17SSLNetVConnection11net_read_ioEP10NetHandlerP7EThread+0x208)[0x666c78]
/usr/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x1f2)[0x66e0e2]
/usr/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0xb4)[0x696c94]
/usr/bin/traffic_server(_ZN7EThread7executeEv+0x4c3)[0x697623]
/usr/bin/traffic_server[0x695c62]
/lib64/libpthread.so.0(+0x7851)[0x2b2505b7c851]
/lib64/libc.so.6(clone+0x6d)[0x2b250800667d]
[Sep 19 03:14:00.159] Manager {0x7ff63f1b07e0} ERROR:
[LocalManager::pollMgmtProcessServer] Server Process terminated due to Sig 11:
Segmentation fault
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (TS-1484) SSL-crashed every now and then with 3.2.0 + SNI-fixes
[
https://issues.apache.org/jira/browse/TS-1484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13458792#comment-13458792
]
Jan-Frode Myklebust edited comment on TS-1484 at 9/20/12 3:14 AM:
--
Not sure I understand correctly, but ...
I have these in my records.config:
CONFIG proxy.config.ssl.server.cert_chain.filename STRING NULL
CONFIG proxy.config.ssl.server.cert.path STRING /etc/pki/tls/certs/
CONFIG proxy.config.ssl.server.private_key.path STRING /etc/pki/tls/private/
CONFIG proxy.config.ssl.CA.cert.filename STRING NULL
CONFIG proxy.config.ssl.CA.cert.path STRING /etc/trafficserver
Are these for the global default section? Should I try pointing them at the
same files as we're using in the dest_ip settings in ssl_multicert.config ?
was (Author: janfrode):
Not sure I understand correctly, but should I
I have these in my records.config:
CONFIG proxy.config.ssl.server.cert_chain.filename STRING NULL
CONFIG proxy.config.ssl.server.cert.path STRING /etc/pki/tls/certs/
CONFIG proxy.config.ssl.server.private_key.path STRING /etc/pki/tls/private/
CONFIG proxy.config.ssl.CA.cert.filename STRING NULL
CONFIG proxy.config.ssl.CA.cert.path STRING /etc/trafficserver
Are these for the global default section? Should I try pointing them at the
same files as we're using in the dest_ip settings in ssl_multicert.config ?
SSL-crashed every now and then with 3.2.0 + SNI-fixes
-
Key: TS-1484
URL: https://issues.apache.org/jira/browse/TS-1484
Project: Traffic Server
Issue Type: Bug
Components: SSL
Affects Versions: 3.2.0
Environment: RHEL6, x86_64, RHEV Virtual machines, IPv4 and IPv6
failover addresses, wildcard SSL-certificates
Reporter: Jan-Frode Myklebust
Assignee: James Peach
We're running ATS v3.2.0 + patch 9c3bebd88eecf6aee1ce346b67460b8e1787752d to
fix support for non-SNI browsers, and every now and (daily I think) then
we're getting this crash:
[Sep 19 03:14:00.147] Server {0x2b2517a7c700} ERROR: SSL ERROR:
SSL_ServerHandShake.
[Sep 19 03:14:00.148] Server {0x2b2517a7c700} ERROR:
SSL::8:error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown
protocol:s23_srvr.c:593:
NOTE: Traffic Server received Sig 11: Segmentation fault
/usr/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0(+0xf500)[0x2b2505b84500]
/usr/lib64/libssl.so.10(SSL_CTX_callback_ctrl+0x5)[0x2b250662f425]
/usr/bin/traffic_server(_ZN17SSLNetVConnection17sslStartHandShakeEiRi+0xf2)[0x6675a2]
/usr/bin/traffic_server(_ZN17SSLNetVConnection11net_read_ioEP10NetHandlerP7EThread+0x208)[0x666c78]
/usr/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x1f2)[0x66e0e2]
/usr/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0xb4)[0x696c94]
/usr/bin/traffic_server(_ZN7EThread7executeEv+0x4c3)[0x697623]
/usr/bin/traffic_server[0x695c62]
/lib64/libpthread.so.0(+0x7851)[0x2b2505b7c851]
/lib64/libc.so.6(clone+0x6d)[0x2b250800667d]
[Sep 19 03:14:00.159] Manager {0x7ff63f1b07e0} ERROR:
[LocalManager::pollMgmtProcessServer] Server Process terminated due to Sig
11: Segmentation fault
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1484) SSL-crashed every now and then with 3.2.0 + SNI-fixes
[
https://issues.apache.org/jira/browse/TS-1484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13458915#comment-13458915
]
Jan-Frode Myklebust commented on TS-1484:
-
I believe those records.config are more or less the defaults on an ATS
installation.. All filename's are NULL. I have all my ssl configs in
ssl_multicert.config:
dest_ip=109.247.114.202
ssl_cert_name=/etc/pki/tls/certs/STAR_services_example_net.crt
ssl_key_name=/etc/pki/tls/private/STAR_services_example_net.key
ssl_ca_name=/etc/pki/tls/certs/STAR_services_example_net.ca-bundle
dest_ip=2a01:798:0:8008::202
ssl_cert_name=/etc/pki/tls/certs/STAR_services_example_net.crt
ssl_key_name=/etc/pki/tls/private/STAR_services_example_net.key
ssl_ca_name=/etc/pki/tls/certs/STAR_services_example_net.ca-bundle
I use the same cert for both IP's here, but the intention is to use other certs
for other IP's later, so I need multicert support.
SSL-crashed every now and then with 3.2.0 + SNI-fixes
-
Key: TS-1484
URL: https://issues.apache.org/jira/browse/TS-1484
Project: Traffic Server
Issue Type: Bug
Components: SSL
Affects Versions: 3.2.0
Environment: RHEL6, x86_64, RHEV Virtual machines, IPv4 and IPv6
failover addresses, wildcard SSL-certificates
Reporter: Jan-Frode Myklebust
Assignee: James Peach
We're running ATS v3.2.0 + patch 9c3bebd88eecf6aee1ce346b67460b8e1787752d to
fix support for non-SNI browsers, and every now and (daily I think) then
we're getting this crash:
[Sep 19 03:14:00.147] Server {0x2b2517a7c700} ERROR: SSL ERROR:
SSL_ServerHandShake.
[Sep 19 03:14:00.148] Server {0x2b2517a7c700} ERROR:
SSL::8:error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown
protocol:s23_srvr.c:593:
NOTE: Traffic Server received Sig 11: Segmentation fault
/usr/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0(+0xf500)[0x2b2505b84500]
/usr/lib64/libssl.so.10(SSL_CTX_callback_ctrl+0x5)[0x2b250662f425]
/usr/bin/traffic_server(_ZN17SSLNetVConnection17sslStartHandShakeEiRi+0xf2)[0x6675a2]
/usr/bin/traffic_server(_ZN17SSLNetVConnection11net_read_ioEP10NetHandlerP7EThread+0x208)[0x666c78]
/usr/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x1f2)[0x66e0e2]
/usr/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0xb4)[0x696c94]
/usr/bin/traffic_server(_ZN7EThread7executeEv+0x4c3)[0x697623]
/usr/bin/traffic_server[0x695c62]
/lib64/libpthread.so.0(+0x7851)[0x2b2505b7c851]
/lib64/libc.so.6(clone+0x6d)[0x2b250800667d]
[Sep 19 03:14:00.159] Manager {0x7ff63f1b07e0} ERROR:
[LocalManager::pollMgmtProcessServer] Server Process terminated due to Sig
11: Segmentation fault
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1484) SSL-crashed every now and then with 3.2.0 + SNI-fixes
[
https://issues.apache.org/jira/browse/TS-1484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13459003#comment-13459003
]
Jan-Frode Myklebust commented on TS-1484:
-
No, we only need ssl for these two addresses at the moment.. But if it's
possible to also enable a set of certificates for the global default context to
work around this problem, that would be an OK workaround for me.
SSL-crashed every now and then with 3.2.0 + SNI-fixes
-
Key: TS-1484
URL: https://issues.apache.org/jira/browse/TS-1484
Project: Traffic Server
Issue Type: Bug
Components: SSL
Affects Versions: 3.2.0
Environment: RHEL6, x86_64, RHEV Virtual machines, IPv4 and IPv6
failover addresses, wildcard SSL-certificates
Reporter: Jan-Frode Myklebust
Assignee: James Peach
We're running ATS v3.2.0 + patch 9c3bebd88eecf6aee1ce346b67460b8e1787752d to
fix support for non-SNI browsers, and every now and (daily I think) then
we're getting this crash:
[Sep 19 03:14:00.147] Server {0x2b2517a7c700} ERROR: SSL ERROR:
SSL_ServerHandShake.
[Sep 19 03:14:00.148] Server {0x2b2517a7c700} ERROR:
SSL::8:error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown
protocol:s23_srvr.c:593:
NOTE: Traffic Server received Sig 11: Segmentation fault
/usr/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0(+0xf500)[0x2b2505b84500]
/usr/lib64/libssl.so.10(SSL_CTX_callback_ctrl+0x5)[0x2b250662f425]
/usr/bin/traffic_server(_ZN17SSLNetVConnection17sslStartHandShakeEiRi+0xf2)[0x6675a2]
/usr/bin/traffic_server(_ZN17SSLNetVConnection11net_read_ioEP10NetHandlerP7EThread+0x208)[0x666c78]
/usr/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x1f2)[0x66e0e2]
/usr/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0xb4)[0x696c94]
/usr/bin/traffic_server(_ZN7EThread7executeEv+0x4c3)[0x697623]
/usr/bin/traffic_server[0x695c62]
/lib64/libpthread.so.0(+0x7851)[0x2b2505b7c851]
/lib64/libc.so.6(clone+0x6d)[0x2b250800667d]
[Sep 19 03:14:00.159] Manager {0x7ff63f1b07e0} ERROR:
[LocalManager::pollMgmtProcessServer] Server Process terminated due to Sig
11: Segmentation fault
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1276) Traffic Server received Sig 11: Segmentation fault
[
https://issues.apache.org/jira/browse/TS-1276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13456965#comment-13456965
]
Jan-Frode Myklebust commented on TS-1276:
-
Conan Wang: which ATS version are you referring to? 3.0.x og 3.2.0?
The stack trace looks very similar to the one I reported here -
http://mail-archives.apache.org/mod_mbox/trafficserver-dev/201209.mbox/%3ccahwpath84cawoitkixzxp2cvpt0gfgnsys6m+oweqp4wpu7...@mail.gmail.com%3e
Traffic Server received Sig 11: Segmentation fault
---
Key: TS-1276
URL: https://issues.apache.org/jira/browse/TS-1276
Project: Traffic Server
Issue Type: Bug
Components: Core
Affects Versions: 3.0.5
Environment: centos 6 x86_64 trafficserver 3.0.5 from git
Reporter: bettydramit
Assignee: weijin
Priority: Critical
Fix For: 3.0.6
Attachments: TS-1276.diff
NOTE: Traffic Server received Sig 11: Segmentation fault
/usr/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0(+0xf4a0)[0x2b499e9594a0]
/usr/bin/traffic_server(_ZN7CacheVC18openWriteStartDoneEiP5Event+0x11d)[0x6653ad]
/usr/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0xb4)[0x6ab884]
/usr/bin/traffic_server(_ZN7EThread7executeEv+0x633)[0x6ac383]
/usr/bin/traffic_server[0x6aa6d2]
/lib64/libpthread.so.0(+0x77f1)[0x2b499e9517f1]
/lib64/libc.so.6(clone+0x6d)[0x2b49a0fdb92d]
[May 28 10:42:08.694] Manager {140401595951072} ERROR:
[LocalManager::pollMgmtProcessServer] Server Process terminated due to Sig
11: Segmentation fault
[May 28 10:42:08.694] Manager {140401595951072} ERROR: (last system error 2:
No such file or directory)
[May 28 10:42:08.694] Manager {140401595951072} ERROR: [Alarms::signalAlarm]
Server Process was reset
[May 28 10:42:08.694] Manager {140401595951072} ERROR: (last system error 2:
No such file or directory)
[May 28 10:42:09.700] Manager {140401595951072} NOTE:
[LocalManager::startProxy] Launching ts process
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (TS-1276) Traffic Server received Sig 11: Segmentation fault
[
https://issues.apache.org/jira/browse/TS-1276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13456965#comment-13456965
]
Jan-Frode Myklebust edited comment on TS-1276 at 9/17/12 11:26 PM:
---
Conan Wang: which ATS version are you referring to? 3.0.x or 3.2.0?
The stack trace looks very similar to the one I reported here -
http://mail-archives.apache.org/mod_mbox/trafficserver-dev/201209.mbox/%3ccahwpath84cawoitkixzxp2cvpt0gfgnsys6m+oweqp4wpu7...@mail.gmail.com%3e
was (Author: janfrode):
Conan Wang: which ATS version are you referring to? 3.0.x og 3.2.0?
The stack trace looks very similar to the one I reported here -
http://mail-archives.apache.org/mod_mbox/trafficserver-dev/201209.mbox/%3ccahwpath84cawoitkixzxp2cvpt0gfgnsys6m+oweqp4wpu7...@mail.gmail.com%3e
Traffic Server received Sig 11: Segmentation fault
---
Key: TS-1276
URL: https://issues.apache.org/jira/browse/TS-1276
Project: Traffic Server
Issue Type: Bug
Components: Core
Affects Versions: 3.0.5
Environment: centos 6 x86_64 trafficserver 3.0.5 from git
Reporter: bettydramit
Assignee: weijin
Priority: Critical
Fix For: 3.0.6
Attachments: TS-1276.diff
NOTE: Traffic Server received Sig 11: Segmentation fault
/usr/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0(+0xf4a0)[0x2b499e9594a0]
/usr/bin/traffic_server(_ZN7CacheVC18openWriteStartDoneEiP5Event+0x11d)[0x6653ad]
/usr/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0xb4)[0x6ab884]
/usr/bin/traffic_server(_ZN7EThread7executeEv+0x633)[0x6ac383]
/usr/bin/traffic_server[0x6aa6d2]
/lib64/libpthread.so.0(+0x77f1)[0x2b499e9517f1]
/lib64/libc.so.6(clone+0x6d)[0x2b49a0fdb92d]
[May 28 10:42:08.694] Manager {140401595951072} ERROR:
[LocalManager::pollMgmtProcessServer] Server Process terminated due to Sig
11: Segmentation fault
[May 28 10:42:08.694] Manager {140401595951072} ERROR: (last system error 2:
No such file or directory)
[May 28 10:42:08.694] Manager {140401595951072} ERROR: [Alarms::signalAlarm]
Server Process was reset
[May 28 10:42:08.694] Manager {140401595951072} ERROR: (last system error 2:
No such file or directory)
[May 28 10:42:09.700] Manager {140401595951072} NOTE:
[LocalManager::startProxy] Launching ts process
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1392) requiring SNI for SSL termination
[ https://issues.apache.org/jira/browse/TS-1392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13435870#comment-13435870 ] Jan-Frode Myklebust commented on TS-1392: - I can confirm that this patch resolved our problem on both the qualsys ssl-server-test, and also for our set-top-boxes. Thanks! requiring SNI for SSL termination - Key: TS-1392 URL: https://issues.apache.org/jira/browse/TS-1392 Project: Traffic Server Issue Type: Bug Components: SSL Affects Versions: 3.2.0 Environment: RHEL6, wildcard SSL certificate Reporter: Jan-Frode Myklebust Assignee: James Peach Priority: Critical Fix For: 3.3.0 It seems ATS require a Server Name Indication to complete the SSL handshake, ref: https://community.qualys.com/thread/10387 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1340) It's very unclear that one needs to list ipv4 and ipv6 ports separately in records.config
[ https://issues.apache.org/jira/browse/TS-1340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan-Frode Myklebust updated TS-1340: Attachment: 0001-Document-the-common-use-case-of-running-a-reverse-pr.patch Give example of the common use-case of listening on port 80 and 443 for ipv4 and ipv6. It's very unclear that one needs to list ipv4 and ipv6 ports separately in records.config - Key: TS-1340 URL: https://issues.apache.org/jira/browse/TS-1340 Project: Traffic Server Issue Type: Improvement Components: Configuration Reporter: Jan-Frode Myklebust Priority: Trivial Attachments: 0001-Document-the-common-use-case-of-running-a-reverse-pr.patch The default records.config should document that one needs to list separate server_ports port configuring ipv4 and ipv6 to get it to listen on both protocols, and not simply list 80:ipv4:ipv6 which the current documentation seems to indicate. I'll attach a patch that gives an example of this for proxy/config/records.config.default.in. Please apply, -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1295) make install should work as non-root user
[
https://issues.apache.org/jira/browse/TS-1295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13293391#comment-13293391
]
Jan-Frode Myklebust commented on TS-1295:
-
Oh, sorry, I must have done a cut'n'paste error. You're mostly right. But got
the install-data-hook backwards. It should be ==:
{noformat}
install-data-hook:
- -chown -R $(pkgsysuser):$(pkgsysgroup) $(DESTDIR)$(pkgsysconfdir)
$(DESTDIR)$(pkgdatadir)
+ if [ `id -un` == root ]; then \
+ chown -R $(pkgsysuser):$(pkgsysgroup)
$(DESTDIR)$(pkgsysconfdir) $(DESTDIR)$(pkgdatadir);\
+ fi
-echo TS_VERSION $(PACKAGE_VERSION)
$(DESTDIR)$(pkgsysconfdir)/trafficserver-release
{noformat}
make install should work as non-root user
-
Key: TS-1295
URL: https://issues.apache.org/jira/browse/TS-1295
Project: Traffic Server
Issue Type: Improvement
Components: Build
Reporter: Jan-Frode Myklebust
Assignee: Leif Hedstrom
Priority: Trivial
Fix For: 3.3.0
Attachments: 0001-Enabling-installing-as-non-root.patch, TS-1295.diff
make install should work as non-root user. Requirng root is bad practice
and causes problems for the fedora build system.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1295) make install should work as non-root user
[ https://issues.apache.org/jira/browse/TS-1295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13293870#comment-13293870 ] Jan-Frode Myklebust commented on TS-1295: - Yes, I agree to your superior formatting :-) Didn't know how to do that myself inside Makefile.am's... make install should work as non-root user - Key: TS-1295 URL: https://issues.apache.org/jira/browse/TS-1295 Project: Traffic Server Issue Type: Improvement Components: Build Reporter: Jan-Frode Myklebust Assignee: Leif Hedstrom Priority: Trivial Fix For: 3.3.0 Attachments: 0001-Enabling-installing-as-non-root.patch, TS-1295.diff make install should work as non-root user. Requirng root is bad practice and causes problems for the fedora build system. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1293) initscript should provide chkconfig header
[ https://issues.apache.org/jira/browse/TS-1293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13292659#comment-13292659 ] Jan-Frode Myklebust commented on TS-1293: - the whole patch is this plus TS-1294. When they are in, I can drop the initscript-patch from the RPM. initscript should provide chkconfig header -- Key: TS-1293 URL: https://issues.apache.org/jira/browse/TS-1293 Project: Traffic Server Issue Type: Bug Components: Packaging Reporter: Jan-Frode Myklebust Priority: Trivial Attachments: 0001-Add-chkconfig-header-to-traffic-server-initscript.-T.patch ATS should provide chkconfig headers in the SysV-style initscript. This is needed on RHEL and pre-systemd fedora. Ref: http://fedoraproject.org/wiki/Packaging:SysVInitScript#Chkconfig_Header -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-1293) initscript should provide chkconfig header
Jan-Frode Myklebust created TS-1293: --- Summary: initscript should provide chkconfig header Key: TS-1293 URL: https://issues.apache.org/jira/browse/TS-1293 Project: Traffic Server Issue Type: Bug Components: Packaging Reporter: Jan-Frode Myklebust Priority: Trivial ATS should provide chkconfig headers in the SysV-style initscript. This is needed on RHEL and pre-systemd fedora. Ref: http://fedoraproject.org/wiki/Packaging:SysVInitScript#Chkconfig_Header -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1293) initscript should provide chkconfig header
[ https://issues.apache.org/jira/browse/TS-1293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan-Frode Myklebust updated TS-1293: Attachment: 0001-Add-chkconfig-header-to-traffic-server-initscript.-T.patch initscript should provide chkconfig header -- Key: TS-1293 URL: https://issues.apache.org/jira/browse/TS-1293 Project: Traffic Server Issue Type: Bug Components: Packaging Reporter: Jan-Frode Myklebust Priority: Trivial Attachments: 0001-Add-chkconfig-header-to-traffic-server-initscript.-T.patch ATS should provide chkconfig headers in the SysV-style initscript. This is needed on RHEL and pre-systemd fedora. Ref: http://fedoraproject.org/wiki/Packaging:SysVInitScript#Chkconfig_Header -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1295) make install should work as non-root user
[ https://issues.apache.org/jira/browse/TS-1295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan-Frode Myklebust updated TS-1295: Attachment: 0001-Enabling-installing-as-non-root.patch make install should work as non-root user - Key: TS-1295 URL: https://issues.apache.org/jira/browse/TS-1295 Project: Traffic Server Issue Type: Improvement Components: Build Reporter: Jan-Frode Myklebust Priority: Trivial Attachments: 0001-Enabling-installing-as-non-root.patch make install should work as non-root user. Requirng root is bad practice and causes problems for the fedora build system. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-885) service trafficserver condrestart does the opposite of what´s intended
[ https://issues.apache.org/jira/browse/TS-885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan-Frode Myklebust updated TS-885: --- Summary: service trafficserver condrestart does the opposite of what´s intended (was: service trafficserver condrestart does the opposite if what´s intended) service trafficserver condrestart does the opposite of what´s intended -- Key: TS-885 URL: https://issues.apache.org/jira/browse/TS-885 Project: Traffic Server Issue Type: Bug Components: Packaging Affects Versions: 3.0.1 Reporter: Jan-Frode Myklebust Priority: Trivial The initscript /etc/init.d/trafficserver on RHEL6 does opposite of what´s intended when called with argument condrestart. If it was already running, it does nothing. If it was not running, it runs stop then start. It´s a trivial bug in rc/trafficserver.in, ref: http://www.mail-archive.com/dev@trafficserver.apache.org/msg02836.html -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
