[jira] [Work started] (TS-1002) log unmapped HOST when pristine_host_hdr disabled
[
https://issues.apache.org/jira/browse/TS-1002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on TS-1002 started by Zhao Yongming.
log unmapped HOST when pristine_host_hdr disabled
-
Key: TS-1002
URL: https://issues.apache.org/jira/browse/TS-1002
Project: Traffic Server
Issue Type: Wish
Components: Logging
Reporter: Conan Wang
Assignee: Zhao Yongming
Priority: Minor
Fix For: 3.1.5
I want to log user request's Host in http header before remap. I write
logs_xml.config, like: %{Host}cqh
When proxy.config.url_remap.pristine_host_hdr is enabled, I will get the
right Host which is not rewritten.
When disable the config, I always get the rewritten/mapped Host which is
not what I need.
logs_xml reference:
http://trafficserver.apache.org/docs/v2/admin/logfmts.htm#66912
--
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-1002) log unmapped HOST when pristine_host_hdr disabled
[
https://issues.apache.org/jira/browse/TS-1002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zhao Yongming updated TS-1002:
--
Attachment: TS-1002.patch
I have create a new cquuh ( client_req_unmapped_url_host ), which is what your
needs, this patch will apply to git master
config:
Format = %cquuc %cquup %cquuh /
result:
http://cdn.zymlinux.net/trafficserver/ts75.png /trafficserver/ts75.png
cdn.zymlinux.net
please test review
log unmapped HOST when pristine_host_hdr disabled
-
Key: TS-1002
URL: https://issues.apache.org/jira/browse/TS-1002
Project: Traffic Server
Issue Type: Wish
Components: Logging
Reporter: Conan Wang
Assignee: Zhao Yongming
Priority: Minor
Fix For: 3.1.5
Attachments: TS-1002.patch
I want to log user request's Host in http header before remap. I write
logs_xml.config, like: %{Host}cqh
When proxy.config.url_remap.pristine_host_hdr is enabled, I will get the
right Host which is not rewritten.
When disable the config, I always get the rewritten/mapped Host which is
not what I need.
logs_xml reference:
http://trafficserver.apache.org/docs/v2/admin/logfmts.htm#66912
--
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-1002) log unmapped HOST when pristine_host_hdr disabled
[
https://issues.apache.org/jira/browse/TS-1002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zhao Yongming updated TS-1002:
--
Fix Version/s: (was: 3.1.5)
3.1.3
log unmapped HOST when pristine_host_hdr disabled
-
Key: TS-1002
URL: https://issues.apache.org/jira/browse/TS-1002
Project: Traffic Server
Issue Type: Wish
Components: Logging
Reporter: Conan Wang
Assignee: Zhao Yongming
Priority: Minor
Fix For: 3.1.3
Attachments: TS-1002.patch
I want to log user request's Host in http header before remap. I write
logs_xml.config, like: %{Host}cqh
When proxy.config.url_remap.pristine_host_hdr is enabled, I will get the
right Host which is not rewritten.
When disable the config, I always get the rewritten/mapped Host which is
not what I need.
logs_xml reference:
http://trafficserver.apache.org/docs/v2/admin/logfmts.htm#66912
--
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-348) Infinite core file creation
[
https://issues.apache.org/jira/browse/TS-348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zhao Yongming updated TS-348:
-
Assignee: Zhao Yongming
we should make sure the admin user is there, the attached patch is a good
proposal.
Infinite core file creation
---
Key: TS-348
URL: https://issues.apache.org/jira/browse/TS-348
Project: Traffic Server
Issue Type: Bug
Components: Configuration
Affects Versions: 2.1.0
Reporter: Mladen Turk
Assignee: Zhao Yongming
Priority: Critical
Fix For: sometime
Attachments: ts-348-proposed.patch
If traffic server is started with non root user account the launch script
endlessly loops in start attempts
generating core.PID file on each iteration.
This creates 80+ MB core file about each second until the disk gets full.
The following log entry is added on each iteration:
E. Mgmt] log == [TrafficManager] using root directory
'/home/mturk/tmp/trafficserver-trunk/trunk-svn/release1/usr/local'
[May 13 12:50:18.299] {3086546656} STATUS: opened
var/log/trafficserver/manager.log
[TrafficServer] using root directory
'/home/mturk/tmp/trafficserver-trunk/trunk-svn/release1/usr/local'
[May 13 12:50:20.830] {1074246896} STATUS: opened
var/log/trafficserver/diags.log
FATAL: Can't change group to user: nobody, gid: 99
/home/mturk/tmp/trafficserver-trunk/trunk-svn/release1/usr/local/bin/traffic_server
- STACK TRACE:
/home/mturk/tmp/trafficserver-trunk/trunk-svn/release1/usr/local/bin/traffic_server(ink_fatal_va+0x8f)[0x83451c7]
/home/mturk/tmp/trafficserver-trunk/trunk-svn/release1/usr/local/bin/traffic_server(ink_fatal_die+0x1d)[0x83451f7]
/home/mturk/tmp/trafficserver-trunk/trunk-svn/release1/usr/local/bin/traffic_server(_Z14change_uid_gidPKc+0xd8)[0x8152a52]
/home/mturk/tmp/trafficserver-trunk/trunk-svn/release1/usr/local/bin/traffic_server(main+0x1296)[0x8153e68]
/lib/libc.so.6(__libc_start_main+0xdc)[0x7bee9c]
/home/mturk/tmp/trafficserver-trunk/trunk-svn/release1/usr/local/bin/traffic_server[0x80f3b31]
[May 13 12:50:21.176] Manager {3086546656} ERROR:
[LocalManager::pollMgmtProcessServer] Server Process terminated due to Sig 6:
Aborted
[May 13 12:50:21.176] Manager {3086546656} ERROR: (last system error 2: No
such file or directory)
[May 13 12:50:21.176] Manager {3086546656} ERROR: [Alarms::signalAlarm]
Server Process was reset
[May 13 12:50:21.176] Manager {3086546656} ERROR: (last system error 2: No
such file or directory)
--
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-1080) Assert under heavy load with logging enabled
[
https://issues.apache.org/jira/browse/TS-1080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13221534#comment-13221534
]
Zhao Yongming commented on TS-1080:
---
hmm, in this case we have fill up the accepting queue with the 512*4 buffers
before the flush thread flushed the flush queue, if we don't increase
FLUSH_ARRAY_SIZE, we should have 2 options:
1, drop the buffer
this may be a good solution for me, as it is better than crashing.
2, speed up the flush thread
well, we will run into another complex direction, we can increase flush
thread? or how can we flush at a higher speed while the IO is limited?
Assert under heavy load with logging enabled
Key: TS-1080
URL: https://issues.apache.org/jira/browse/TS-1080
Project: Traffic Server
Issue Type: Bug
Components: Logging
Reporter: Leif Hedstrom
Priority: Critical
Fix For: 3.1.4
Given enough load (in the 100,000 QPS or more), we run out of some sort of
buffer space, with an assert of
{code}
#0 0x2ba719d50285 in __GI_raise (sig=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1 0x2ba719d51b9b in __GI_abort () at abort.c:91
#2 0x006b561a in ink_die_die_die (retval=optimized out) at
ink_error.cc:43
#3 ink_fatal_va(int, const char *, typedef __va_list_tag __va_list_tag *)
(return_code=optimized out, message_format=optimized out,
ap=0x7fff7275a7d8) at ink_error.cc:65
#4 0x006b56a7 in ink_fatal (return_code=optimized out,
message_format=optimized out) at ink_error.cc:73
#5 0x006b4970 in _ink_assert (a=0x6fd380
_num_flush_buffers[_open_flush_array] FLUSH_ARRAY_SIZE, f=optimized
out, l=96) at ink_assert.cc:44
#6 0x005a8b34 in add_to_flush_queue (buffer=0x2ba7443ca970,
this=0x22fb918) at LogObject.h:96
#7 LogObject::_checkout_write (this=0x22fb880, write_offset=0x7fff7275add8,
bytes_needed=152) at LogObject.cc:455
#8 0x005a8fd3 in LogObject::log (this=0x22fb880, lad=0x7fff7275b030,
text_entry=0x0) at LogObject.cc:580
#9 0x0058e956 in log (lad=0x7fff7275b030, this=optimized out) at
LogObject.h:475
#10 Log::access (lad=0x7fff7275b030) at Log.cc:1086
{code}
Increasing FLUSH_ARRAY_SIZE alleviates the problem, but really, we shouldn't
end up in this situation at all.
--
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
