[jira] [Commented] (TS-306) enable log rotation for diags.log
[ https://issues.apache.org/jira/browse/TS-306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14618906#comment-14618906 ] Daniel Xu commented on TS-306: -- RFC on implementation plan: - Create an independent base class with a lot of the functionality from LogFile (file rotation, byte tracking, timestamps, etc) - Make LogFile inherit from the base class - Make Diags use the base class to manage diags.log and traffic.out A major benefit of this plan is that no code needs to be copied and pasted. It would also be very easy to add new basic functionality for log files. Drawbacks include more complexity and a mixing of what are two different types of logging systems. I'm mainly looking for design critique. > enable log rotation for diags.log > - > > Key: TS-306 > URL: https://issues.apache.org/jira/browse/TS-306 > Project: Traffic Server > Issue Type: Improvement > Components: Logging >Reporter: Miles Libbey >Assignee: Daniel Xu > Labels: newbie > Fix For: 6.1.0 > > > (from yahoo bug 913896) > Original description > by Leif Hedstrom 3 years ago at 2006-12-04 12:42 > There might be reasons why this file might get filled up, e.g. libraries used > by plugins producing output on STDOUT/STDERR. A few suggestions have been > made, to somehow rotate traffic.out. One possible solution (suggested by > Ryan) is to use cronolog (http://cronolog.org/), which seems like a fine idea. > > > Comment 1 > by Joseph Rothrock 2 years ago at 2007-10-17 09:13:24 > Maybe consider rolling diags.log as well. -Feature enhancement. > > Comment 2 > by Kevin Dalley 13 months ago at 2009-03-04 15:32:18 > When traffic.out gets filled up, error.log stops filing up, even though > rotation is turned on. This is > counter-intuitive. Rotation does not control traffic.out, but a large > traffic.out will stop error.log from being > written. > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (TS-306) enable log rotation for diags.log
[ https://issues.apache.org/jira/browse/TS-306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14618906#comment-14618906 ] Daniel Xu edited comment on TS-306 at 7/9/15 7:07 PM: -- RFC on implementation plan: - Create an independent base class with a lot of the functionality from LogFile (file rotation, byte tracking, timestamps, etc) - Make LogFile inherit from the base class - Make Diags use the base class to manage diags.log and traffic.out A major benefit of this plan is that no code needs to be copied and pasted. It would also be very easy to add new basic functionality for log files. Drawbacks include more complexity and a mixing of what are two different types of logging systems. I'm mainly looking for design critique. [~jamespeach], any thoughts? was (Author: danobi): RFC on implementation plan: - Create an independent base class with a lot of the functionality from LogFile (file rotation, byte tracking, timestamps, etc) - Make LogFile inherit from the base class - Make Diags use the base class to manage diags.log and traffic.out A major benefit of this plan is that no code needs to be copied and pasted. It would also be very easy to add new basic functionality for log files. Drawbacks include more complexity and a mixing of what are two different types of logging systems. I'm mainly looking for design critique. > enable log rotation for diags.log > - > > Key: TS-306 > URL: https://issues.apache.org/jira/browse/TS-306 > Project: Traffic Server > Issue Type: Improvement > Components: Logging >Reporter: Miles Libbey >Assignee: Daniel Xu > Labels: newbie > Fix For: 6.1.0 > > > (from yahoo bug 913896) > Original description > by Leif Hedstrom 3 years ago at 2006-12-04 12:42 > There might be reasons why this file might get filled up, e.g. libraries used > by plugins producing output on STDOUT/STDERR. A few suggestions have been > made, to somehow rotate traffic.out. One possible solution (suggested by > Ryan) is to use cronolog (http://cronolog.org/), which seems like a fine idea. > > > Comment 1 > by Joseph Rothrock 2 years ago at 2007-10-17 09:13:24 > Maybe consider rolling diags.log as well. -Feature enhancement. > > Comment 2 > by Kevin Dalley 13 months ago at 2009-03-04 15:32:18 > When traffic.out gets filled up, error.log stops filing up, even though > rotation is turned on. This is > counter-intuitive. Rotation does not control traffic.out, but a large > traffic.out will stop error.log from being > written. > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (TS-306) enable log rotation for diags.log
[ https://issues.apache.org/jira/browse/TS-306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14618906#comment-14618906 ] Daniel Xu edited comment on TS-306 at 7/9/15 7:08 PM: -- RFC on implementation plan: - Create an independent base class with a lot of the functionality from LogFile (file rotation, byte tracking, timestamps, etc) - Make LogFile inherit from the base class - Make Diags use the base class to manage diags.log and traffic.out A major benefit of this plan is that no code needs to be copied and pasted. It would also be very easy to add new basic functionality for log files. Drawbacks include more complexity and a mixing of what are two different types of logging systems. I'm mainly looking for design critique. edit [~jamespeach], any thoughts? was (Author: danobi): RFC on implementation plan: - Create an independent base class with a lot of the functionality from LogFile (file rotation, byte tracking, timestamps, etc) - Make LogFile inherit from the base class - Make Diags use the base class to manage diags.log and traffic.out A major benefit of this plan is that no code needs to be copied and pasted. It would also be very easy to add new basic functionality for log files. Drawbacks include more complexity and a mixing of what are two different types of logging systems. I'm mainly looking for design critique. [~jamespeach], any thoughts? > enable log rotation for diags.log > - > > Key: TS-306 > URL: https://issues.apache.org/jira/browse/TS-306 > Project: Traffic Server > Issue Type: Improvement > Components: Logging >Reporter: Miles Libbey >Assignee: Daniel Xu > Labels: newbie > Fix For: 6.1.0 > > > (from yahoo bug 913896) > Original description > by Leif Hedstrom 3 years ago at 2006-12-04 12:42 > There might be reasons why this file might get filled up, e.g. libraries used > by plugins producing output on STDOUT/STDERR. A few suggestions have been > made, to somehow rotate traffic.out. One possible solution (suggested by > Ryan) is to use cronolog (http://cronolog.org/), which seems like a fine idea. > > > Comment 1 > by Joseph Rothrock 2 years ago at 2007-10-17 09:13:24 > Maybe consider rolling diags.log as well. -Feature enhancement. > > Comment 2 > by Kevin Dalley 13 months ago at 2009-03-04 15:32:18 > When traffic.out gets filled up, error.log stops filing up, even though > rotation is turned on. This is > counter-intuitive. Rotation does not control traffic.out, but a large > traffic.out will stop error.log from being > written. > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-3757) Update documentation to include proxy.config.log.periodic_tasks_interval
Daniel Xu created TS-3757: - Summary: Update documentation to include proxy.config.log.periodic_tasks_interval Key: TS-3757 URL: https://issues.apache.org/jira/browse/TS-3757 Project: Traffic Server Issue Type: Bug Components: Documentation Reporter: Daniel Xu TS-3435 allowed for the periodic tasks interval in Log.cc to be specified in records.config. Documentation should be updated to reflect this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-3776) traffic_server failed assert `s->current.server->had_connect_fail()`
Daniel Xu created TS-3776: - Summary: traffic_server failed assert `s->current.server->had_connect_fail()` Key: TS-3776 URL: https://issues.apache.org/jira/browse/TS-3776 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: Daniel Xu Running latest build from github repo as of bug post. Error: traffic_server fatally terminates after traffic_manager spawns it, and then traffic_server gets automatically restarted. How to reproduce: -Set up ATS in a reverse proxy configuration, where the OS is some local http server. -Run 'bin/trafficserver start' -View stack trace in traffic.out Stack trace: - [E. Mgmt] log ==> [TrafficManager] using root directory '/opt/ats' traffic_server: using root directory '/opt/ats' FATAL: HttpTransact.cc:3828: failed assert `s->current.server->had_connect_fail()` traffic_server: Aborted (Signal sent by tkill() 5398 99)traffic_server - STACK TRACE: /opt/ats/bin/traffic_server(_Z19crash_logger_invokeiP7siginfoPv+0xc3)[0x4fd6f5] /lib64/libpthread.so.0(+0x3dd480f710)[0x2aad89487710] /lib64/libc.so.6(gsignal+0x35)[0x3dd4432625] /lib64/libc.so.6(abort+0x175)[0x3dd4433e05] /opt/ats/lib/libtsutil.so.6(_Z12ink_fatal_vaPKcP13__va_list_tag+0x0)[0x2aad8900a851] /opt/ats/lib/libtsutil.so.6(_Z9ink_fatalPKcz+0x0)[0x2aad8900a908] /opt/ats/lib/libtsutil.so.6(_Z10ink_pfatalPKcz+0x0)[0x2aad8900a9cd] /opt/ats/lib/libtsutil.so.6(+0x3a44a)[0x2aad8900844a] /opt/ats/bin/traffic_server(_ZN12HttpTransact33handle_server_connection_not_openEPNS_5StateE+0x1b5)[0x5fe39d] /opt/ats/bin/traffic_server(_ZN12HttpTransact27handle_response_from_serverEPNS_5StateE+0x3d2)[0x5fd49e] /opt/ats/bin/traffic_server(_ZN12HttpTransact14HandleResponseEPNS_5StateE+0x6f5)[0x5fbd5b] /opt/ats/bin/traffic_server(_ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE+0x84)[0x5de85c] /opt/ats/bin/traffic_server(_ZN6HttpSM25handle_server_setup_errorEiPv+0x65a)[0x5d8894] /opt/ats/bin/traffic_server(_ZN6HttpSM33state_read_server_response_headerEiPv+0x217)[0x5cae5f] /opt/ats/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0x270)[0x5cdddc] /opt/ats/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50068e] /opt/ats/bin/traffic_server[0x76746a] /opt/ats/bin/traffic_server[0x76780a] /opt/ats/bin/traffic_server[0x767f7d] /opt/ats/bin/traffic_server(_ZN18UnixNetVConnection11net_read_ioEP10NetHandlerP7EThread+0x2b)[0x76a2d9] /opt/ats/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x6de)[0x75f89e] /opt/ats/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50068e] /opt/ats/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x136)[0x789c46] /opt/ats/bin/traffic_server(_ZN7EThread7executeEv+0x49b)[0x78a267] /opt/ats/bin/traffic_server(main+0x13ef)[0x53282a] /lib64/libc.so.6(__libc_start_main+0xfd)[0x3dd441ed5d] /opt/ats/bin/traffic_server[0x4e5ac9] traffic_server: using root directory '/opt/ats' -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-3838) Alphabetize switches for help flag
Daniel Xu created TS-3838: - Summary: Alphabetize switches for help flag Key: TS-3838 URL: https://issues.apache.org/jira/browse/TS-3838 Project: Traffic Server Issue Type: Improvement Components: Core Reporter: Daniel Xu Eg. `./traffic_server -h` would print all the flags in alphabetized order. It would make it easier for the user to quickly find the flag they're looking for. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3838) Alphabetize switches for help flag
[ https://issues.apache.org/jira/browse/TS-3838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Xu updated TS-3838: -- Labels: newbie (was: ) Priority: Minor (was: Major) > Alphabetize switches for help flag > -- > > Key: TS-3838 > URL: https://issues.apache.org/jira/browse/TS-3838 > Project: Traffic Server > Issue Type: Improvement > Components: Core >Reporter: Daniel Xu >Priority: Minor > Labels: newbie > > Eg. `./traffic_server -h` would print all the flags in alphabetized order. > It would make it easier for the user to quickly find the flag they're looking > for. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-4286) Wrong configuration instructions in docs for disabling caching
Daniel Xu created TS-4286: - Summary: Wrong configuration instructions in docs for disabling caching Key: TS-4286 URL: https://issues.apache.org/jira/browse/TS-4286 Project: Traffic Server Issue Type: Bug Components: Docs Reporter: Daniel Xu https://docs.trafficserver.apache.org/en/latest/admin-guide/configuration/cache-basics.en.html#disabling-http-object-caching The docs tell you to turn off HTTP proxying via proxy.config.http.enabled instead of telling you to turn off caching via proxy.config.http.cache.http -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-4250) Clang-format breaks on Centos 6
[ https://issues.apache.org/jira/browse/TS-4250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15236275#comment-15236275 ] Daniel Xu commented on TS-4250: --- I read the docs for sha1sum and I can see why it would fail (the -a flag doesn't exist). However, I couldn't reproduce this on my machine for whatever reason. I made a new pull request that I think should fix it. > Clang-format breaks on Centos 6 > --- > > Key: TS-4250 > URL: https://issues.apache.org/jira/browse/TS-4250 > Project: Traffic Server > Issue Type: Bug >Reporter: Susan Hinrichs >Assignee: Daniel Xu > Labels: newbie > Fix For: 6.2.0 > > > When I run "make clang-format" on my Cento 6 vm it fails saying it cannot > find shasum. If I set the environment variable SHASUM to sha1sum (which is > present on my VM), it works. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-2056) When proxy.config.http.negative_caching_enabled = 1 we cache errors even if Cache-Control: no-cache is sent from the origin
[
https://issues.apache.org/jira/browse/TS-2056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15239987#comment-15239987
]
Daniel Xu commented on TS-2056:
---
Could not reproduce. ATS was caching without the Cache-Control: no-cache, but
as soon as I added the no-cache header ATS would no longer cache. Same goes for
private & no-store.
Looks like it might've been fixed since 2013.
> When proxy.config.http.negative_caching_enabled = 1 we cache errors even if
> Cache-Control: no-cache is sent from the origin
> ---
>
> Key: TS-2056
> URL: https://issues.apache.org/jira/browse/TS-2056
> Project: Traffic Server
> Issue Type: Bug
>Reporter: Phil Sorber
>Assignee: Daniel Xu
> Labels: C, newbie
> Fix For: 6.2.0
>
>
> {noformat}
> HTTP/1.1 500 Internal Server Error
> Content-Type: text/plain
> Cache-Control: no-cache
> Date: Sun, 21 Jul 2013 17:20:00 GMT
> Expires: Sun, 21 Jul 2013 17:50:00 GMT
> Age: 38
> Content-Length: 40
> Connection: keep-alive
> Via: http/1.1 XX (ApacheTrafficServer/3.3.5-dev [uScHs f p eN:t cCHi
> p s ])
> Server: ATS/3.3.5-dev
> {noformat}
> While this is a grey area since we are already breaking the spec by negative
> caching, I think we should still not cache this when explicitly told not to
> by the origin and [~zwoop] agrees!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TS-4354) Diagnostic logging improvements
Daniel Xu created TS-4354: - Summary: Diagnostic logging improvements Key: TS-4354 URL: https://issues.apache.org/jira/browse/TS-4354 Project: Traffic Server Issue Type: Bug Components: Logging Reporter: Daniel Xu Some things could be improved in the Diags class. In order of relative importance: * Unit tests & functional tests for Diags & BaseLogFile class * Make log_log_...() functions run time configurable. ie. make it so we can choose to turn on those debugging statements at run time ** As jpeach mentioned, environment variables or global flag or other could work * Combine bind_stdout() & bind_stderr() into a single helper function called something like rebind(int oldfd, int new_fd) * Make BaseLogFile::m_fp private and accessible with a getter -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-4626) LogFile::close_file should not delete m_log handle
[
https://issues.apache.org/jira/browse/TS-4626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15517440#comment-15517440
]
Daniel Xu commented on TS-4626:
---
Hi @Michael Chai,
I took a look at the code and I think I agree with you. I'll make a fix for
this after TS-4072 lands in master.
Dan
> LogFile::close_file should not delete m_log handle
> --
>
> Key: TS-4626
> URL: https://issues.apache.org/jira/browse/TS-4626
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Reporter: Michael Chai
>Assignee: Daniel Xu
> Fix For: 7.1.0
>
>
> When log file was deleted on the disk, LogFile::check_fd will close file
> handle and reopen again.delete m_log at this point will cause
> LogFile::open_file return "LOG_FILE_COULD_NOT_OPEN_FILE" . otherwise, will
> cause trafficserver crash at LogFile::preproc_and_try_delete
> 300 if (!m_log->m_start_time) {
> (gdb) bt
> #0 0x0068245f in LogFile::preproc_and_try_delete (this=0x1132eb0,
> lb=0x7fffdc000da0) at LogFile.cc:300
> #1 0x0068caa6 in LogBufferManager::preproc_buffers (this=0x1132970,
> sink=0x1132eb0) at LogObject.cc:77
> #2 0x00691a53 in LogObject::preproc_buffers (this=0x1132ae0, idx=0)
> at LogObject.h:146
> #3 0x006901c3 in LogObjectManager::preproc_buffers (this=0x1127228,
> idx=0) at LogObject.cc:1126
> #4 0x0066b668 in Log::preproc_thread_main (args=0x1131edc) at
> Log.cc:1168
> #5 0x0066ce9d in LoggingPreprocContinuation::mainEvent
> (this=0x1131ea0) at Log.cc:279
> #6 0x0050d662 in Continuation::handleEvent (this=0x1131ea0, event=1,
> data=0x11529a0) at ../iocore/eventsystem/I_Continuation.h:153
> #7 0x007a1e9f in EThread::execute (this=0x707a1010) at
> UnixEThread.cc:298
> #8 0x007a0d0c in spawn_thread_internal (a=0x1131ef0) at Thread.cc:84
> #9 0x764740a4 in start_thread (arg=0x707a0700) at
> pthread_create.c:309
> #10 0x7541c04d in clone () at
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
> (gdb) p m_log
> $1 = (BaseLogFile *) 0x0
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (TS-4626) LogFile::close_file should not delete m_log handle
[
https://issues.apache.org/jira/browse/TS-4626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15517440#comment-15517440
]
Daniel Xu edited comment on TS-4626 at 9/23/16 8:09 PM:
Hi [~chaiman_ats],
I took a look at the code and I think I agree with you. I'll make a fix for
this after TS-4072 lands in master.
Dan
was (Author: danobi):
Hi @Michael Chai,
I took a look at the code and I think I agree with you. I'll make a fix for
this after TS-4072 lands in master.
Dan
> LogFile::close_file should not delete m_log handle
> --
>
> Key: TS-4626
> URL: https://issues.apache.org/jira/browse/TS-4626
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Reporter: Michael Chai
>Assignee: Daniel Xu
> Fix For: 7.1.0
>
>
> When log file was deleted on the disk, LogFile::check_fd will close file
> handle and reopen again.delete m_log at this point will cause
> LogFile::open_file return "LOG_FILE_COULD_NOT_OPEN_FILE" . otherwise, will
> cause trafficserver crash at LogFile::preproc_and_try_delete
> 300 if (!m_log->m_start_time) {
> (gdb) bt
> #0 0x0068245f in LogFile::preproc_and_try_delete (this=0x1132eb0,
> lb=0x7fffdc000da0) at LogFile.cc:300
> #1 0x0068caa6 in LogBufferManager::preproc_buffers (this=0x1132970,
> sink=0x1132eb0) at LogObject.cc:77
> #2 0x00691a53 in LogObject::preproc_buffers (this=0x1132ae0, idx=0)
> at LogObject.h:146
> #3 0x006901c3 in LogObjectManager::preproc_buffers (this=0x1127228,
> idx=0) at LogObject.cc:1126
> #4 0x0066b668 in Log::preproc_thread_main (args=0x1131edc) at
> Log.cc:1168
> #5 0x0066ce9d in LoggingPreprocContinuation::mainEvent
> (this=0x1131ea0) at Log.cc:279
> #6 0x0050d662 in Continuation::handleEvent (this=0x1131ea0, event=1,
> data=0x11529a0) at ../iocore/eventsystem/I_Continuation.h:153
> #7 0x007a1e9f in EThread::execute (this=0x707a1010) at
> UnixEThread.cc:298
> #8 0x007a0d0c in spawn_thread_internal (a=0x1131ef0) at Thread.cc:84
> #9 0x764740a4 in start_thread (arg=0x707a0700) at
> pthread_create.c:309
> #10 0x7541c04d in clone () at
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
> (gdb) p m_log
> $1 = (BaseLogFile *) 0x0
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (TS-4399) Management API breaks diagnostic log rotation
[
https://issues.apache.org/jira/browse/TS-4399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Xu reassigned TS-4399:
-
Assignee: Daniel Xu (was: Alan M. Carroll)
> Management API breaks diagnostic log rotation
> -
>
> Key: TS-4399
> URL: https://issues.apache.org/jira/browse/TS-4399
> Project: Traffic Server
> Issue Type: Bug
> Components: Logging, Management API
>Reporter: James Peach
>Assignee: Daniel Xu
> Fix For: 7.1.0
>
>
> Start up Traffic Server:
> {code}
> 0 26950 1 0 10:13AM ?? 0:00.01 /opt/ats/bin/traffic_cop
>-2 26951 26950 0 10:13AM ?? 0:00.02 /opt/ats/bin/traffic_manager
> --bind_stdout /opt/ats/var/log/trafficserver/traffic.out --bind_stderr
> /opt/ats/var/log/trafficserver/traffic.out
>-2 26952 26951 0 10:13AM ?? 0:00.08 /opt/ats/bin/traffic_server
> -M --bind_stdout /opt/ats/var/log/trafficserver/traffic.out --bind_stderr
> /opt/ats/var/log/trafficserver/traffic.out --httpport 8080:fd=12
> {code}
> Now restart it using {{traffic_line -S}} followed by {{traffic_line -U}}:
> {code}
> 0 26950 1 0 10:13AM ?? 0:00.01 /opt/ats/bin/traffic_cop
>-2 26951 26950 0 10:13AM ?? 0:00.05 /opt/ats/bin/traffic_manager
> --bind_stdout /opt/ats/var/log/trafficserver/traffic.out --bind_stderr
> /opt/ats/var/log/trafficserver/traffic.out
>-2 26967 26951 0 10:13AM ?? 0:00.12 /opt/ats/bin/traffic_server
> -M --httpport 8080:fd=20
> {code}
> Note that we lost the {{\--bind_stdout}} and {{\--bind_stderr}} options.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-4399) Management API breaks diagnostic log rotation
[
https://issues.apache.org/jira/browse/TS-4399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15530495#comment-15530495
]
Daniel Xu commented on TS-4399:
---
I can reproduce this bug. Looking into it now.
> Management API breaks diagnostic log rotation
> -
>
> Key: TS-4399
> URL: https://issues.apache.org/jira/browse/TS-4399
> Project: Traffic Server
> Issue Type: Bug
> Components: Logging, Management API
>Reporter: James Peach
>Assignee: Daniel Xu
> Fix For: 7.1.0
>
>
> Start up Traffic Server:
> {code}
> 0 26950 1 0 10:13AM ?? 0:00.01 /opt/ats/bin/traffic_cop
>-2 26951 26950 0 10:13AM ?? 0:00.02 /opt/ats/bin/traffic_manager
> --bind_stdout /opt/ats/var/log/trafficserver/traffic.out --bind_stderr
> /opt/ats/var/log/trafficserver/traffic.out
>-2 26952 26951 0 10:13AM ?? 0:00.08 /opt/ats/bin/traffic_server
> -M --bind_stdout /opt/ats/var/log/trafficserver/traffic.out --bind_stderr
> /opt/ats/var/log/trafficserver/traffic.out --httpport 8080:fd=12
> {code}
> Now restart it using {{traffic_line -S}} followed by {{traffic_line -U}}:
> {code}
> 0 26950 1 0 10:13AM ?? 0:00.01 /opt/ats/bin/traffic_cop
>-2 26951 26950 0 10:13AM ?? 0:00.05 /opt/ats/bin/traffic_manager
> --bind_stdout /opt/ats/var/log/trafficserver/traffic.out --bind_stderr
> /opt/ats/var/log/trafficserver/traffic.out
>-2 26967 26951 0 10:13AM ?? 0:00.12 /opt/ats/bin/traffic_server
> -M --httpport 8080:fd=20
> {code}
> Note that we lost the {{\--bind_stdout}} and {{\--bind_stderr}} options.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (TS-4400) TSProxyStateSet persist cache clearing across restart
[
https://issues.apache.org/jira/browse/TS-4400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Xu reassigned TS-4400:
-
Assignee: Daniel Xu
> TSProxyStateSet persist cache clearing across restart
> -
>
> Key: TS-4400
> URL: https://issues.apache.org/jira/browse/TS-4400
> Project: Traffic Server
> Issue Type: Bug
> Components: Management API
>Reporter: James Peach
>Assignee: Daniel Xu
> Fix For: 7.1.0
>
>
> If you use {{TSProxyStateSet}} and and pass the options to clear the cache,
> these options are persisted so that subsequent restarts will also clear the
> cache. This seems pretty bad and likely to cause accidents. The options
> should be one-shot.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-4400) TSProxyStateSet persist cache clearing across restart
[
https://issues.apache.org/jira/browse/TS-4400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15530928#comment-15530928
]
Daniel Xu commented on TS-4400:
---
The issue is that in mgmt/api/CoreAPI.cc, on line 189, the CoreAPI overrides
the proxy_options in LocalManager and never clears proxy_options after TS
starts back up.
Here is the line in question: {{lmgmt->proxy_options = ats_strdup(tsArgs)}}
> TSProxyStateSet persist cache clearing across restart
> -
>
> Key: TS-4400
> URL: https://issues.apache.org/jira/browse/TS-4400
> Project: Traffic Server
> Issue Type: Bug
> Components: Management API
>Reporter: James Peach
>Assignee: Daniel Xu
> Fix For: 7.1.0
>
>
> If you use {{TSProxyStateSet}} and and pass the options to clear the cache,
> these options are persisted so that subsequent restarts will also clear the
> cache. This seems pretty bad and likely to cause accidents. The options
> should be one-shot.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (TS-4399) Management API breaks diagnostic log rotation
[
https://issues.apache.org/jira/browse/TS-4399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15530955#comment-15530955
]
Daniel Xu edited comment on TS-4399 at 9/28/16 9:39 PM:
[~jamespeach]: We can't remove {{-tsArgs}} and **only** use
{{proxy.config.proxy_binary_opts}} because the Records subsystem (ie.
{{REC_readString()}}) is initialized after we want to write output to
diagnostic logs.
I agree this is a bug. I think it would be easy to do a quick and dirty fix,
but I also think there's room for a better solution. We should think about it
in conjunction with TS-4400. See my comment [over
here|https://issues.apache.org/jira/browse/TS-4400?focusedCommentId=15530928&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15530928].
was (Author: danobi):
[~jamespeach]: We can't remove {{-tsArgs}} and **only** use
{{proxy.config.proxy_binary_opts}} because the Records subsystem (ie.
{{REC_readString()}} is initialized after we want to write output to diagnostic
logs.
I agree this is a bug. I think it would be easy to do a quick and dirty fix,
but I also think there's room for a better solution. We should think about it
in conjunction with TS-4400. See my comment [over
here|https://issues.apache.org/jira/browse/TS-4400?focusedCommentId=15530928&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15530928].
> Management API breaks diagnostic log rotation
> -
>
> Key: TS-4399
> URL: https://issues.apache.org/jira/browse/TS-4399
> Project: Traffic Server
> Issue Type: Bug
> Components: Logging, Management API
>Reporter: James Peach
>Assignee: Daniel Xu
> Fix For: 7.1.0
>
>
> Start up Traffic Server:
> {code}
> 0 26950 1 0 10:13AM ?? 0:00.01 /opt/ats/bin/traffic_cop
>-2 26951 26950 0 10:13AM ?? 0:00.02 /opt/ats/bin/traffic_manager
> --bind_stdout /opt/ats/var/log/trafficserver/traffic.out --bind_stderr
> /opt/ats/var/log/trafficserver/traffic.out
>-2 26952 26951 0 10:13AM ?? 0:00.08 /opt/ats/bin/traffic_server
> -M --bind_stdout /opt/ats/var/log/trafficserver/traffic.out --bind_stderr
> /opt/ats/var/log/trafficserver/traffic.out --httpport 8080:fd=12
> {code}
> Now restart it using {{traffic_line -S}} followed by {{traffic_line -U}}:
> {code}
> 0 26950 1 0 10:13AM ?? 0:00.01 /opt/ats/bin/traffic_cop
>-2 26951 26950 0 10:13AM ?? 0:00.05 /opt/ats/bin/traffic_manager
> --bind_stdout /opt/ats/var/log/trafficserver/traffic.out --bind_stderr
> /opt/ats/var/log/trafficserver/traffic.out
>-2 26967 26951 0 10:13AM ?? 0:00.12 /opt/ats/bin/traffic_server
> -M --httpport 8080:fd=20
> {code}
> Note that we lost the {{\--bind_stdout}} and {{\--bind_stderr}} options.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-4399) Management API breaks diagnostic log rotation
[
https://issues.apache.org/jira/browse/TS-4399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15530955#comment-15530955
]
Daniel Xu commented on TS-4399:
---
[~jamespeach]: We can't remove {{-tsArgs}} and **only** use
{{proxy.config.proxy_binary_opts}} because the Records subsystem (ie.
{{REC_readString()}} is initialized after we want to write output to diagnostic
logs.
I agree this is a bug. I think it would be easy to do a quick and dirty fix,
but I also think there's room for a better solution. We should think about it
in conjunction with TS-4400. See my comment [over
here|https://issues.apache.org/jira/browse/TS-4400?focusedCommentId=15530928&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15530928].
> Management API breaks diagnostic log rotation
> -
>
> Key: TS-4399
> URL: https://issues.apache.org/jira/browse/TS-4399
> Project: Traffic Server
> Issue Type: Bug
> Components: Logging, Management API
>Reporter: James Peach
>Assignee: Daniel Xu
> Fix For: 7.1.0
>
>
> Start up Traffic Server:
> {code}
> 0 26950 1 0 10:13AM ?? 0:00.01 /opt/ats/bin/traffic_cop
>-2 26951 26950 0 10:13AM ?? 0:00.02 /opt/ats/bin/traffic_manager
> --bind_stdout /opt/ats/var/log/trafficserver/traffic.out --bind_stderr
> /opt/ats/var/log/trafficserver/traffic.out
>-2 26952 26951 0 10:13AM ?? 0:00.08 /opt/ats/bin/traffic_server
> -M --bind_stdout /opt/ats/var/log/trafficserver/traffic.out --bind_stderr
> /opt/ats/var/log/trafficserver/traffic.out --httpport 8080:fd=12
> {code}
> Now restart it using {{traffic_line -S}} followed by {{traffic_line -U}}:
> {code}
> 0 26950 1 0 10:13AM ?? 0:00.01 /opt/ats/bin/traffic_cop
>-2 26951 26950 0 10:13AM ?? 0:00.05 /opt/ats/bin/traffic_manager
> --bind_stdout /opt/ats/var/log/trafficserver/traffic.out --bind_stderr
> /opt/ats/var/log/trafficserver/traffic.out
>-2 26967 26951 0 10:13AM ?? 0:00.12 /opt/ats/bin/traffic_server
> -M --httpport 8080:fd=20
> {code}
> Note that we lost the {{\--bind_stdout}} and {{\--bind_stderr}} options.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (TS-4399) Management API breaks diagnostic log rotation
[
https://issues.apache.org/jira/browse/TS-4399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15530955#comment-15530955
]
Daniel Xu edited comment on TS-4399 at 9/28/16 9:41 PM:
Edit: hold on, I think this comment is wrong. I need to think about this a
little more
--
[~jamespeach]: We can't remove {{-tsArgs}} and **only** use
{{proxy.config.proxy_binary_opts}} because the Records subsystem (ie.
{{REC_readString()}}) is initialized after we want to write output to
diagnostic logs.
I agree this is a bug. I think it would be easy to do a quick and dirty fix,
but I also think there's room for a better solution. We should think about it
in conjunction with TS-4400. See my comment [over
here|https://issues.apache.org/jira/browse/TS-4400?focusedCommentId=15530928&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15530928].
was (Author: danobi):
[~jamespeach]: We can't remove {{-tsArgs}} and **only** use
{{proxy.config.proxy_binary_opts}} because the Records subsystem (ie.
{{REC_readString()}}) is initialized after we want to write output to
diagnostic logs.
I agree this is a bug. I think it would be easy to do a quick and dirty fix,
but I also think there's room for a better solution. We should think about it
in conjunction with TS-4400. See my comment [over
here|https://issues.apache.org/jira/browse/TS-4400?focusedCommentId=15530928&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15530928].
> Management API breaks diagnostic log rotation
> -
>
> Key: TS-4399
> URL: https://issues.apache.org/jira/browse/TS-4399
> Project: Traffic Server
> Issue Type: Bug
> Components: Logging, Management API
>Reporter: James Peach
>Assignee: Daniel Xu
> Fix For: 7.1.0
>
>
> Start up Traffic Server:
> {code}
> 0 26950 1 0 10:13AM ?? 0:00.01 /opt/ats/bin/traffic_cop
>-2 26951 26950 0 10:13AM ?? 0:00.02 /opt/ats/bin/traffic_manager
> --bind_stdout /opt/ats/var/log/trafficserver/traffic.out --bind_stderr
> /opt/ats/var/log/trafficserver/traffic.out
>-2 26952 26951 0 10:13AM ?? 0:00.08 /opt/ats/bin/traffic_server
> -M --bind_stdout /opt/ats/var/log/trafficserver/traffic.out --bind_stderr
> /opt/ats/var/log/trafficserver/traffic.out --httpport 8080:fd=12
> {code}
> Now restart it using {{traffic_line -S}} followed by {{traffic_line -U}}:
> {code}
> 0 26950 1 0 10:13AM ?? 0:00.01 /opt/ats/bin/traffic_cop
>-2 26951 26950 0 10:13AM ?? 0:00.05 /opt/ats/bin/traffic_manager
> --bind_stdout /opt/ats/var/log/trafficserver/traffic.out --bind_stderr
> /opt/ats/var/log/trafficserver/traffic.out
>-2 26967 26951 0 10:13AM ?? 0:00.12 /opt/ats/bin/traffic_server
> -M --httpport 8080:fd=20
> {code}
> Note that we lost the {{\--bind_stdout}} and {{\--bind_stderr}} options.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (TS-4399) Management API breaks diagnostic log rotation
[
https://issues.apache.org/jira/browse/TS-4399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15530955#comment-15530955
]
Daniel Xu edited comment on TS-4399 at 9/28/16 9:46 PM:
Edit: hold on, I think this comment is wrong. I need to think about this a
little more
--
-[~jamespeach]: We can't remove {{-tsArgs}} and **only** use
{{proxy.config.proxy_binary_opts}} because the Records subsystem (ie.
{{REC_readString()}}) is initialized after we want to write output to
diagnostic logs.-
I agree this is a bug. I think it would be easy to do a quick and dirty fix,
but I also think there's room for a better solution. We should think about it
in conjunction with TS-4400. See my comment [over
here|https://issues.apache.org/jira/browse/TS-4400?focusedCommentId=15530928&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15530928].
was (Author: danobi):
Edit: hold on, I think this comment is wrong. I need to think about this a
little more
--
[~jamespeach]: We can't remove {{-tsArgs}} and **only** use
{{proxy.config.proxy_binary_opts}} because the Records subsystem (ie.
{{REC_readString()}}) is initialized after we want to write output to
diagnostic logs.
I agree this is a bug. I think it would be easy to do a quick and dirty fix,
but I also think there's room for a better solution. We should think about it
in conjunction with TS-4400. See my comment [over
here|https://issues.apache.org/jira/browse/TS-4400?focusedCommentId=15530928&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15530928].
> Management API breaks diagnostic log rotation
> -
>
> Key: TS-4399
> URL: https://issues.apache.org/jira/browse/TS-4399
> Project: Traffic Server
> Issue Type: Bug
> Components: Logging, Management API
>Reporter: James Peach
>Assignee: Daniel Xu
> Fix For: 7.1.0
>
>
> Start up Traffic Server:
> {code}
> 0 26950 1 0 10:13AM ?? 0:00.01 /opt/ats/bin/traffic_cop
>-2 26951 26950 0 10:13AM ?? 0:00.02 /opt/ats/bin/traffic_manager
> --bind_stdout /opt/ats/var/log/trafficserver/traffic.out --bind_stderr
> /opt/ats/var/log/trafficserver/traffic.out
>-2 26952 26951 0 10:13AM ?? 0:00.08 /opt/ats/bin/traffic_server
> -M --bind_stdout /opt/ats/var/log/trafficserver/traffic.out --bind_stderr
> /opt/ats/var/log/trafficserver/traffic.out --httpport 8080:fd=12
> {code}
> Now restart it using {{traffic_line -S}} followed by {{traffic_line -U}}:
> {code}
> 0 26950 1 0 10:13AM ?? 0:00.01 /opt/ats/bin/traffic_cop
>-2 26951 26950 0 10:13AM ?? 0:00.05 /opt/ats/bin/traffic_manager
> --bind_stdout /opt/ats/var/log/trafficserver/traffic.out --bind_stderr
> /opt/ats/var/log/trafficserver/traffic.out
>-2 26967 26951 0 10:13AM ?? 0:00.12 /opt/ats/bin/traffic_server
> -M --httpport 8080:fd=20
> {code}
> Note that we lost the {{\--bind_stdout}} and {{\--bind_stderr}} options.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TS-3694) Fix function documentation to Log::error
Daniel Xu created TS-3694:
-
Summary: Fix function documentation to Log::error
Key: TS-3694
URL: https://issues.apache.org/jira/browse/TS-3694
Project: Traffic Server
Issue Type: Improvement
Components: Logging
Reporter: Daniel Xu
The description for this function seems to be out of date. The note directly
contradicts what the function actually does.
{code:title=Log.cc|borderStyle=solid}
/*-
Log::error
Make an entry into the current error log. For convenience, it is given in
both variable argument (format, ...) and stdarg (format, va_list) forms.
Note that Log::error could call Log::va_error after calling va_start
so that va_error handles the statistics update. However, to make
Log::error slightly more efficient this is not the case. The
downside is that one has to be careful to update both functions if
need be.
-*/
int
Log::error(const char *format, ...)
{
va_list ap;
int ret;
va_start(ap, format);
ret = Log::va_error(format, ap);
va_end(ap);
return ret;
}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3694) Fix function documentation to Log::error
[
https://issues.apache.org/jira/browse/TS-3694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Xu updated TS-3694:
--
Priority: Trivial (was: Major)
> Fix function documentation to Log::error
>
>
> Key: TS-3694
> URL: https://issues.apache.org/jira/browse/TS-3694
> Project: Traffic Server
> Issue Type: Improvement
> Components: Logging
>Reporter: Daniel Xu
>Assignee: Daniel Xu
>Priority: Trivial
> Fix For: Docs
>
>
> The description for this function seems to be out of date. The note directly
> contradicts what the function actually does.
> {code:title=Log.cc|borderStyle=solid}
> /*-
> Log::error
> Make an entry into the current error log. For convenience, it is given in
> both variable argument (format, ...) and stdarg (format, va_list) forms.
> Note that Log::error could call Log::va_error after calling va_start
> so that va_error handles the statistics update. However, to make
> Log::error slightly more efficient this is not the case. The
> downside is that one has to be careful to update both functions if
> need be.
> -*/
> int
> Log::error(const char *format, ...)
> {
> va_list ap;
> int ret;
> va_start(ap, format);
> ret = Log::va_error(format, ap);
> va_end(ap);
> return ret;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TS-3718) Unused member function 'read_metadata()' in LogFile.h
Daniel Xu created TS-3718: - Summary: Unused member function 'read_metadata()' in LogFile.h Key: TS-3718 URL: https://issues.apache.org/jira/browse/TS-3718 Project: Traffic Server Issue Type: Improvement Components: Logging Reporter: Daniel Xu The function is declared in LogFile.h, but not defined anywhere in the code base. It is also not referenced anywhere. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3718) Unused members in LogFile.h
[ https://issues.apache.org/jira/browse/TS-3718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Xu updated TS-3718: -- Priority: Trivial (was: Major) Description: read_metadata() is declared in LogFile.h, but not defined anywhere in the code base. It is also not referenced anywhere else. m_size_bytes is a public variable initialized to 0 in the default LogFile constructor, however, it is not used or referenced anywhere in the code base. was:The function is declared in LogFile.h, but not defined anywhere in the code base. It is also not referenced anywhere. Summary: Unused members in LogFile.h (was: Unused member function 'read_metadata()' in LogFile.h) > Unused members in LogFile.h > --- > > Key: TS-3718 > URL: https://issues.apache.org/jira/browse/TS-3718 > Project: Traffic Server > Issue Type: Improvement > Components: Logging >Reporter: Daniel Xu >Priority: Trivial > > read_metadata() is declared in LogFile.h, but not defined anywhere in the > code base. It is also not referenced anywhere else. > m_size_bytes is a public variable initialized to 0 in the default LogFile > constructor, however, it is not used or referenced anywhere in the code base. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-3741) Broken doxygen documentation link
Daniel Xu created TS-3741: - Summary: Broken doxygen documentation link Key: TS-3741 URL: https://issues.apache.org/jira/browse/TS-3741 Project: Traffic Server Issue Type: Bug Components: Documentation Reporter: Daniel Xu The function index link on [here | http://trafficserver.readthedocs.org/en/latest/sdk/preface/how-to-use-this-book.en.html] is broken. It's also broken in at least one other place. Can't quite remember, though. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-4000) Extraneous `setvbuf()` in Diags.cc
Daniel Xu created TS-4000:
-
Summary: Extraneous `setvbuf()` in Diags.cc
Key: TS-4000
URL: https://issues.apache.org/jira/browse/TS-4000
Project: Traffic Server
Issue Type: Bug
Components: Logging
Reporter: Daniel Xu
Line 596:
{noformat}
status = setvbuf(blf->m_fp, NULL, _IOLBF, 512);
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (TS-4000) Extraneous `setvbuf()` in Diags.cc
[
https://issues.apache.org/jira/browse/TS-4000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Xu closed TS-4000.
-
Resolution: Fixed
> Extraneous `setvbuf()` in Diags.cc
> --
>
> Key: TS-4000
> URL: https://issues.apache.org/jira/browse/TS-4000
> Project: Traffic Server
> Issue Type: Bug
> Components: Logging
>Reporter: Daniel Xu
>
> Line 596:
> {noformat}
> status = setvbuf(blf->m_fp, NULL, _IOLBF, 512);
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TS-4022) Incorrect behavior with remap prefix matching
Daniel Xu created TS-4022: - Summary: Incorrect behavior with remap prefix matching Key: TS-4022 URL: https://issues.apache.org/jira/browse/TS-4022 Project: Traffic Server Issue Type: Bug Components: Remap API Reporter: Daniel Xu If you have two remap rules like this: `map https://localhost:8081/1 https://httpbin.org/html` `map https://localhost:8081/10 https://httpbin.org/html` When connection to `https://localhost:8081/10`, ATS will first replace `https://localhost:8081/1` with `https://httpbin.org/html`, and then append the `0` to the end. So your final URI will look like: `https://httpbin.org/html0` If two remaps are explicitly specified, both should work. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-4022) Incorrect behavior with remap prefix matching
[ https://issues.apache.org/jira/browse/TS-4022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Xu updated TS-4022: -- Description: If you have two remap rules like this: `map https://localhost:8081/1 https://httpbin.org/html` `map https://localhost:8081/10 https://httpbin.org/html` When connecting to `https://localhost:8081/10`, ATS will first replace `https://localhost:8081/1` with `https://httpbin.org/html`, and then append the `0` to the end. So your final URI will look like: `https://httpbin.org/html0` If two remaps are explicitly specified, both should work. was: If you have two remap rules like this: `map https://localhost:8081/1 https://httpbin.org/html` `map https://localhost:8081/10 https://httpbin.org/html` When connection to `https://localhost:8081/10`, ATS will first replace `https://localhost:8081/1` with `https://httpbin.org/html`, and then append the `0` to the end. So your final URI will look like: `https://httpbin.org/html0` If two remaps are explicitly specified, both should work. > Incorrect behavior with remap prefix matching > - > > Key: TS-4022 > URL: https://issues.apache.org/jira/browse/TS-4022 > Project: Traffic Server > Issue Type: Bug > Components: Remap API >Reporter: Daniel Xu > > If you have two remap rules like this: > `map https://localhost:8081/1 https://httpbin.org/html` > `map https://localhost:8081/10 https://httpbin.org/html` > When connecting to `https://localhost:8081/10`, ATS will first replace > `https://localhost:8081/1` with `https://httpbin.org/html`, and then append > the `0` to the end. > So your final URI will look like: > `https://httpbin.org/html0` > If two remaps are explicitly specified, both should work. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-4022) Incorrect behavior with remap prefix matching
[ https://issues.apache.org/jira/browse/TS-4022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Xu updated TS-4022: -- Description: If you have two remap rules like this: `map https://localhost:8081/1 https://httpbin.org/html` `map https://localhost:8081/10 https://httpbin.org/html` When connecting to `https://localhost:8081/10`, ATS will first replace `https://localhost:8081/1` with `https://httpbin.org/html`, and then append the `0` to the end. So your final URI will look like: `https://httpbin.org/html0`, which should not be the case. If two remaps are explicitly specified, both should work. was: If you have two remap rules like this: `map https://localhost:8081/1 https://httpbin.org/html` `map https://localhost:8081/10 https://httpbin.org/html` When connecting to `https://localhost:8081/10`, ATS will first replace `https://localhost:8081/1` with `https://httpbin.org/html`, and then append the `0` to the end. So your final URI will look like: `https://httpbin.org/html0` , which should not be the case. If two remaps are explicitly specified, both should work. > Incorrect behavior with remap prefix matching > - > > Key: TS-4022 > URL: https://issues.apache.org/jira/browse/TS-4022 > Project: Traffic Server > Issue Type: Bug > Components: Remap API >Reporter: Daniel Xu > > If you have two remap rules like this: > `map https://localhost:8081/1 https://httpbin.org/html` > `map https://localhost:8081/10 https://httpbin.org/html` > When connecting to `https://localhost:8081/10`, ATS will first replace > `https://localhost:8081/1` with `https://httpbin.org/html`, and then append > the `0` to the end. > So your final URI will look like: > `https://httpbin.org/html0`, which should not be the case. > If two remaps are explicitly specified, both should work. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-4022) Incorrect behavior with remap prefix matching
[ https://issues.apache.org/jira/browse/TS-4022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Xu updated TS-4022: -- Description: If you have two remap rules like this: `map https://localhost:8081/1 https://httpbin.org/html` `map https://localhost:8081/10 https://httpbin.org/html` When connecting to `https://localhost:8081/10`, ATS will first replace `https://localhost:8081/1` with `https://httpbin.org/html`, and then append the `0` to the end. So your final URI will look like: `https://httpbin.org/html0` , which should not be the case. If two remaps are explicitly specified, both should work. was: If you have two remap rules like this: `map https://localhost:8081/1 https://httpbin.org/html` `map https://localhost:8081/10 https://httpbin.org/html` When connecting to `https://localhost:8081/10`, ATS will first replace `https://localhost:8081/1` with `https://httpbin.org/html`, and then append the `0` to the end. So your final URI will look like: `https://httpbin.org/html0` If two remaps are explicitly specified, both should work. > Incorrect behavior with remap prefix matching > - > > Key: TS-4022 > URL: https://issues.apache.org/jira/browse/TS-4022 > Project: Traffic Server > Issue Type: Bug > Components: Remap API >Reporter: Daniel Xu > > If you have two remap rules like this: > `map https://localhost:8081/1 https://httpbin.org/html` > `map https://localhost:8081/10 https://httpbin.org/html` > When connecting to `https://localhost:8081/10`, ATS will first replace > `https://localhost:8081/1` with `https://httpbin.org/html`, and then append > the `0` to the end. > So your final URI will look like: > `https://httpbin.org/html0` > , which should not be the case. > If two remaps are explicitly specified, both should work. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-4022) Incorrect behavior with remap prefix matching
[ https://issues.apache.org/jira/browse/TS-4022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15004683#comment-15004683 ] Daniel Xu commented on TS-4022: --- Ok, then I think what I was seeing was expected behavior. To clarify what I previously said about the 404, I realized a little later that the 404s were happening because the remap rules did a greedy substitution and left a bunch of trailing characters in the URI. What I put in the bug description is what had happened to the best of my knowledge. > Incorrect behavior with remap prefix matching > - > > Key: TS-4022 > URL: https://issues.apache.org/jira/browse/TS-4022 > Project: Traffic Server > Issue Type: Bug > Components: Remap API >Reporter: Daniel Xu > > If you have two remap rules like this: > `map https://localhost:8081/1 https://httpbin.org/html` > `map https://localhost:8081/10 https://httpbin.org/html` > When connecting to `https://localhost:8081/10`, ATS will first replace > `https://localhost:8081/1` with `https://httpbin.org/html`, and then append > the `0` to the end. > So your final URI will look like: > `https://httpbin.org/html0`, which should not be the case. > If two remaps are explicitly specified, both should work. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (TS-4022) Incorrect behavior with remap prefix matching
[ https://issues.apache.org/jira/browse/TS-4022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Xu closed TS-4022. - Resolution: Invalid > Incorrect behavior with remap prefix matching > - > > Key: TS-4022 > URL: https://issues.apache.org/jira/browse/TS-4022 > Project: Traffic Server > Issue Type: Bug > Components: Remap API >Reporter: Daniel Xu > > If you have two remap rules like this: > `map https://localhost:8081/1 https://httpbin.org/html` > `map https://localhost:8081/10 https://httpbin.org/html` > When connecting to `https://localhost:8081/10`, ATS will first replace > `https://localhost:8081/1` with `https://httpbin.org/html`, and then append > the `0` to the end. > So your final URI will look like: > `https://httpbin.org/html0`, which should not be the case. > If two remaps are explicitly specified, both should work. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-4043) Prevent bogus FQDN characters in host header
Daniel Xu created TS-4043: - Summary: Prevent bogus FQDN characters in host header Key: TS-4043 URL: https://issues.apache.org/jira/browse/TS-4043 Project: Traffic Server Issue Type: Bug Components: Security Reporter: Daniel Xu Assignee: Leif Hedstrom Currently ATS isn't checking if a character is valid before letting it in as a hostname. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-4054) Incorrect ink_assert behavior in Diags.cc
Daniel Xu created TS-4054: - Summary: Incorrect ink_assert behavior in Diags.cc Key: TS-4054 URL: https://issues.apache.org/jira/browse/TS-4054 Project: Traffic Server Issue Type: Bug Components: Logging Reporter: Daniel Xu In `lib/ts/Diags.cc:setup_diagslog()`, the statement `ink_assert(diags_log == NULL)` is incorrect. It should instead be: `if (blf == NULL) return` We should not use an assert here either because when the function is passed a NULL `blf`, it means that some test doesn't want to use the diags.log log file and we should just not set up diagslog. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-4057) Missing check for system call error
Daniel Xu created TS-4057: - Summary: Missing check for system call error Key: TS-4057 URL: https://issues.apache.org/jira/browse/TS-4057 Project: Traffic Server Issue Type: Bug Components: Logging Reporter: Daniel Xu `elevating_open()` doesn't check for EACCES in the failure case of `open()`. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-4058) Logging doesn't work when TS is compiled and run w/ --with-user
[ https://issues.apache.org/jira/browse/TS-4058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Xu updated TS-4058: -- Summary: Logging doesn't work when TS is compiled and run w/ --with-user (was: Logging doesn't work with TS is compiled and run w/ --with-user) > Logging doesn't work when TS is compiled and run w/ --with-user > --- > > Key: TS-4058 > URL: https://issues.apache.org/jira/browse/TS-4058 > Project: Traffic Server > Issue Type: Bug > Components: Logging >Reporter: Daniel Xu > > ie. we run this _without_ sudo. > traffic_cop output seems to point to permission errors -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-4058) Logging doesn't work with TS is compiled and run w/ --with-user
Daniel Xu created TS-4058: - Summary: Logging doesn't work with TS is compiled and run w/ --with-user Key: TS-4058 URL: https://issues.apache.org/jira/browse/TS-4058 Project: Traffic Server Issue Type: Bug Components: Logging Reporter: Daniel Xu ie. we run this _without_ sudo. traffic_cop output seems to point to permission errors -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-4058) Logging doesn't work when TS is compiled and run w/ --with-user
[ https://issues.apache.org/jira/browse/TS-4058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Xu updated TS-4058: -- Description: ie. we run this _without_ sudo. traffic_cop output seems to point to permission errors that occur within traffic_manager was: ie. we run this _without_ sudo. traffic_cop output seems to point to permission errors > Logging doesn't work when TS is compiled and run w/ --with-user > --- > > Key: TS-4058 > URL: https://issues.apache.org/jira/browse/TS-4058 > Project: Traffic Server > Issue Type: Bug > Components: Logging >Reporter: Daniel Xu >Assignee: Daniel Xu > > ie. we run this _without_ sudo. > traffic_cop output seems to point to permission errors that occur within > traffic_manager -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-4058) Logging doesn't work when TS is compiled and run w/ --with-user
[
https://issues.apache.org/jira/browse/TS-4058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15045823#comment-15045823
]
Daniel Xu commented on TS-4058:
---
The issue is in `Diags::set_std{out,err}_output()` because we indiscriminately
call `ElevateAccess()`. There are a few issues preventing us from an "easy"
fix. We need root access for the whole function because there's a bunch of
`BaseLogFile` logic that assumes we have access to the log files we want. The
best way (in my opinion) would be to make a function in `ink_cap.cc` that can
check to see if we are able to elevate to root. We could then just use that
function to decide if we want to call `ElevateAccess` at all.
I'm not sure how to implement that feature and I probably won't be able to get
around to this again for a few weeks.
> Logging doesn't work when TS is compiled and run w/ --with-user
> ---
>
> Key: TS-4058
> URL: https://issues.apache.org/jira/browse/TS-4058
> Project: Traffic Server
> Issue Type: Bug
> Components: Logging
>Reporter: Daniel Xu
>Assignee: Daniel Xu
>
> ie. we run this _without_ sudo.
> traffic_cop output seems to point to permission errors that occur within
> traffic_manager
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (TS-4058) Logging doesn't work when TS is compiled and run w/ --with-user
[
https://issues.apache.org/jira/browse/TS-4058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15045823#comment-15045823
]
Daniel Xu edited comment on TS-4058 at 12/7/15 9:57 PM:
The issue is in `Diags::set_std {out,err} _output()` because we
indiscriminately call `ElevateAccess()`. There are a few issues preventing us
from an "easy" fix. We need root access for the whole function because there's
a bunch of `BaseLogFile` logic that assumes we have access to the log files we
want. That is to say, we don't have a way to tell if we ran TS as root or as
some other user. The best way (in my opinion) would be to make a function in
`ink_cap.cc` that can check to see if we are able to elevate to root. We could
then just use that function to decide if we want to call `ElevateAccess` at
all.
I'm not sure how to implement that feature and I probably won't be able to get
around to this again for a few weeks.
was (Author: danobi):
The issue is in `Diags::set_std {out,err} _output()` because we
indiscriminately call `ElevateAccess()`. There are a few issues preventing us
from an "easy" fix. We need root access for the whole function because there's
a bunch of `BaseLogFile` logic that assumes we have access to the log files we
want. The best way (in my opinion) would be to make a function in `ink_cap.cc`
that can check to see if we are able to elevate to root. We could then just use
that function to decide if we want to call `ElevateAccess` at all.
I'm not sure how to implement that feature and I probably won't be able to get
around to this again for a few weeks.
> Logging doesn't work when TS is compiled and run w/ --with-user
> ---
>
> Key: TS-4058
> URL: https://issues.apache.org/jira/browse/TS-4058
> Project: Traffic Server
> Issue Type: Bug
> Components: Logging
>Reporter: Daniel Xu
>Assignee: Daniel Xu
>
> ie. we run this _without_ sudo.
> traffic_cop output seems to point to permission errors that occur within
> traffic_manager
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (TS-4058) Logging doesn't work when TS is compiled and run w/ --with-user
[
https://issues.apache.org/jira/browse/TS-4058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15045823#comment-15045823
]
Daniel Xu edited comment on TS-4058 at 12/7/15 9:56 PM:
The issue is in `Diags::set_std {out,err} _output()` because we
indiscriminately call `ElevateAccess()`. There are a few issues preventing us
from an "easy" fix. We need root access for the whole function because there's
a bunch of `BaseLogFile` logic that assumes we have access to the log files we
want. The best way (in my opinion) would be to make a function in `ink_cap.cc`
that can check to see if we are able to elevate to root. We could then just use
that function to decide if we want to call `ElevateAccess` at all.
I'm not sure how to implement that feature and I probably won't be able to get
around to this again for a few weeks.
was (Author: danobi):
The issue is in `Diags::set_std{out,err}_output()` because we indiscriminately
call `ElevateAccess()`. There are a few issues preventing us from an "easy"
fix. We need root access for the whole function because there's a bunch of
`BaseLogFile` logic that assumes we have access to the log files we want. The
best way (in my opinion) would be to make a function in `ink_cap.cc` that can
check to see if we are able to elevate to root. We could then just use that
function to decide if we want to call `ElevateAccess` at all.
I'm not sure how to implement that feature and I probably won't be able to get
around to this again for a few weeks.
> Logging doesn't work when TS is compiled and run w/ --with-user
> ---
>
> Key: TS-4058
> URL: https://issues.apache.org/jira/browse/TS-4058
> Project: Traffic Server
> Issue Type: Bug
> Components: Logging
>Reporter: Daniel Xu
>Assignee: Daniel Xu
>
> ie. we run this _without_ sudo.
> traffic_cop output seems to point to permission errors that occur within
> traffic_manager
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-4058) Logging doesn't work when TS is compiled and run w/ --with-user
[
https://issues.apache.org/jira/browse/TS-4058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15045903#comment-15045903
]
Daniel Xu commented on TS-4058:
---
If you run:
{noformat}
./configure --with-user=danielxu --prefix=/home/danielxu/ats-test-env && cd
~ats-test-env && bin/traffic_cop -od
{noformat}
You'll see error messages about permission denied.
The reason it does that is because we always try to elevate our permissions to
root in Diags without checking if we even have the ability to do that. We can't
easily fix this problem unless we know if we are allowed to elevate to root. I
can't figure out how to check if we are allowed to elevate to root.
> Logging doesn't work when TS is compiled and run w/ --with-user
> ---
>
> Key: TS-4058
> URL: https://issues.apache.org/jira/browse/TS-4058
> Project: Traffic Server
> Issue Type: Bug
> Components: Logging
>Reporter: Daniel Xu
>Assignee: Daniel Xu
>
> ie. we run this _without_ sudo.
> traffic_cop output seems to point to permission errors that occur within
> traffic_manager
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (TS-4058) Logging doesn't work when TS is compiled and run w/ --with-user
[
https://issues.apache.org/jira/browse/TS-4058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15045903#comment-15045903
]
Daniel Xu edited comment on TS-4058 at 12/7/15 10:37 PM:
-
If you run:
{noformat}
./configure --with-user=danielxu --prefix=/home/danielxu/ats-test-env && cd
~/ats-test-env && bin/traffic_cop -od
{noformat}
You'll see error messages about permission denied.
The reason it does that is because we always try to elevate our permissions to
root in Diags without checking if we even have the ability to do that. We can't
easily fix this problem unless we know if we are allowed to elevate to root. I
can't figure out how to check if we are allowed to elevate to root.
was (Author: danobi):
If you run:
{noformat}
./configure --with-user=danielxu --prefix=/home/danielxu/ats-test-env && cd
~ats-test-env && bin/traffic_cop -od
{noformat}
You'll see error messages about permission denied.
The reason it does that is because we always try to elevate our permissions to
root in Diags without checking if we even have the ability to do that. We can't
easily fix this problem unless we know if we are allowed to elevate to root. I
can't figure out how to check if we are allowed to elevate to root.
> Logging doesn't work when TS is compiled and run w/ --with-user
> ---
>
> Key: TS-4058
> URL: https://issues.apache.org/jira/browse/TS-4058
> Project: Traffic Server
> Issue Type: Bug
> Components: Logging
>Reporter: Daniel Xu
>Assignee: Daniel Xu
>
> ie. we run this _without_ sudo.
> traffic_cop output seems to point to permission errors that occur within
> traffic_manager
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (TS-4058) Logging doesn't work when TS is compiled and run w/ --with-user
[
https://issues.apache.org/jira/browse/TS-4058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15045903#comment-15045903
]
Daniel Xu edited comment on TS-4058 at 12/7/15 10:37 PM:
-
If you run:
{noformat}
./configure --with-user=danielxu --prefix=/home/danielxu/ats-test-env && make
install && cd ~/ats-test-env && bin/traffic_cop -od
{noformat}
You'll see error messages about permission denied.
The reason it does that is because we always try to elevate our permissions to
root in Diags without checking if we even have the ability to do that. We can't
easily fix this problem unless we know if we are allowed to elevate to root. I
can't figure out how to check if we are allowed to elevate to root.
was (Author: danobi):
If you run:
{noformat}
./configure --with-user=danielxu --prefix=/home/danielxu/ats-test-env && cd
~/ats-test-env && bin/traffic_cop -od
{noformat}
You'll see error messages about permission denied.
The reason it does that is because we always try to elevate our permissions to
root in Diags without checking if we even have the ability to do that. We can't
easily fix this problem unless we know if we are allowed to elevate to root. I
can't figure out how to check if we are allowed to elevate to root.
> Logging doesn't work when TS is compiled and run w/ --with-user
> ---
>
> Key: TS-4058
> URL: https://issues.apache.org/jira/browse/TS-4058
> Project: Traffic Server
> Issue Type: Bug
> Components: Logging
>Reporter: Daniel Xu
>Assignee: Daniel Xu
>
> ie. we run this _without_ sudo.
> traffic_cop output seems to point to permission errors that occur within
> traffic_manager
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (TS-4058) Logging doesn't work when TS is compiled and run w/ --with-user
[
https://issues.apache.org/jira/browse/TS-4058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15045903#comment-15045903
]
Daniel Xu edited comment on TS-4058 at 12/7/15 10:39 PM:
-
If you run:
{noformat}
./configure --with-user=danielxu --prefix=/home/danielxu/ats-test-env && make
install && cd ~/ats-test-env && bin/traffic_cop -od
{noformat}
You'll see error messages about permission denied.
That happens because we always try to elevate our permissions to root in Diags
without checking if we have the ability to do that. We can't fix this problem
unless we know if we are allowed to elevate to root. I can't figure out how to
check if we are allowed to elevate to root.
was (Author: danobi):
If you run:
{noformat}
./configure --with-user=danielxu --prefix=/home/danielxu/ats-test-env && make
install && cd ~/ats-test-env && bin/traffic_cop -od
{noformat}
You'll see error messages about permission denied.
The reason it does that is because we always try to elevate our permissions to
root in Diags without checking if we even have the ability to do that. We can't
easily fix this problem unless we know if we are allowed to elevate to root. I
can't figure out how to check if we are allowed to elevate to root.
> Logging doesn't work when TS is compiled and run w/ --with-user
> ---
>
> Key: TS-4058
> URL: https://issues.apache.org/jira/browse/TS-4058
> Project: Traffic Server
> Issue Type: Bug
> Components: Logging
>Reporter: Daniel Xu
>Assignee: Daniel Xu
>
> ie. we run this _without_ sudo.
> traffic_cop output seems to point to permission errors that occur within
> traffic_manager
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (TS-4058) Logging doesn't work when TS is compiled and run w/ --with-user
[
https://issues.apache.org/jira/browse/TS-4058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15045903#comment-15045903
]
Daniel Xu edited comment on TS-4058 at 12/7/15 10:41 PM:
-
If you run:
{noformat}
./configure --with-user=danielxu --prefix=/home/danielxu/ats-test-env && make
install && cd ~/ats-test-env && bin/traffic_cop -od
{noformat}
You'll see error messages about permission denied. You won't see `traffic.out`
or `diags.log` created or populated in ~/ats-test-env/var/log/trafficserver
either.
That happens because we always try to elevate our permissions to root in Diags
without checking if we have the ability to do that. We can't fix this problem
unless we know if we are allowed to elevate to root. I can't figure out how to
check if we are allowed to elevate to root.
was (Author: danobi):
If you run:
{noformat}
./configure --with-user=danielxu --prefix=/home/danielxu/ats-test-env && make
install && cd ~/ats-test-env && bin/traffic_cop -od
{noformat}
You'll see error messages about permission denied.
That happens because we always try to elevate our permissions to root in Diags
without checking if we have the ability to do that. We can't fix this problem
unless we know if we are allowed to elevate to root. I can't figure out how to
check if we are allowed to elevate to root.
> Logging doesn't work when TS is compiled and run w/ --with-user
> ---
>
> Key: TS-4058
> URL: https://issues.apache.org/jira/browse/TS-4058
> Project: Traffic Server
> Issue Type: Bug
> Components: Logging
>Reporter: Daniel Xu
>Assignee: Daniel Xu
>
> ie. we run this _without_ sudo.
> traffic_cop output seems to point to permission errors that occur within
> traffic_manager
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-4058) Logging doesn't work when TS is compiled and run w/ --with-user
[ https://issues.apache.org/jira/browse/TS-4058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15045936#comment-15045936 ] Daniel Xu commented on TS-4058: --- Yes. It wasn't caught earlier because there's no tests to catch it. > Logging doesn't work when TS is compiled and run w/ --with-user > --- > > Key: TS-4058 > URL: https://issues.apache.org/jira/browse/TS-4058 > Project: Traffic Server > Issue Type: Bug > Components: Logging >Reporter: Daniel Xu >Assignee: Daniel Xu > > ie. we run this _without_ sudo. > traffic_cop output seems to point to permission errors that occur within > traffic_manager -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-4058) Logging doesn't work when TS is compiled and run w/ --with-user
[ https://issues.apache.org/jira/browse/TS-4058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15046448#comment-15046448 ] Daniel Xu commented on TS-4058: --- Noted. I'll think about some ideas to avoid these permission issues > Logging doesn't work when TS is compiled and run w/ --with-user > --- > > Key: TS-4058 > URL: https://issues.apache.org/jira/browse/TS-4058 > Project: Traffic Server > Issue Type: Bug > Components: Logging >Reporter: Daniel Xu >Assignee: Daniel Xu > > ie. we run this _without_ sudo. > traffic_cop output seems to point to permission errors that occur within > traffic_manager -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (TS-4058) Logging doesn't work when TS is compiled and run w/ --with-user
[ https://issues.apache.org/jira/browse/TS-4058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15046448#comment-15046448 ] Daniel Xu edited comment on TS-4058 at 12/8/15 6:31 AM: Noted. I'll think about some ideas to avoid these permission issues. In the meantime, an appropriate workaround would just be to run TS as a privileged user. was (Author: danobi): Noted. I'll think about some ideas to avoid these permission issues > Logging doesn't work when TS is compiled and run w/ --with-user > --- > > Key: TS-4058 > URL: https://issues.apache.org/jira/browse/TS-4058 > Project: Traffic Server > Issue Type: Bug > Components: Logging >Reporter: Daniel Xu >Assignee: Daniel Xu > > ie. we run this _without_ sudo. > traffic_cop output seems to point to permission errors that occur within > traffic_manager -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-4084) Empty README.md file
Daniel Xu created TS-4084: - Summary: Empty README.md file Key: TS-4084 URL: https://issues.apache.org/jira/browse/TS-4084 Project: Traffic Server Issue Type: Bug Components: Documentation Reporter: Daniel Xu The empty README.md file is causing github not to display the correct README. Also the empty file doesn't do anything -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-4086) Documentation for proxy.config.log.rolling_size_mb doesn't mention minimum size
Daniel Xu created TS-4086: - Summary: Documentation for proxy.config.log.rolling_size_mb doesn't mention minimum size Key: TS-4086 URL: https://issues.apache.org/jira/browse/TS-4086 Project: Traffic Server Issue Type: Bug Components: Logging Reporter: Daniel Xu The minimum size to roll with is 10mb, but the documentation doesn't mention this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-4086) Documentation for proxy.config.log.rolling_size_mb doesn't mention minimum size
[ https://issues.apache.org/jira/browse/TS-4086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Xu updated TS-4086: -- Fix Version/s: 6.1.0 > Documentation for proxy.config.log.rolling_size_mb doesn't mention minimum > size > > > Key: TS-4086 > URL: https://issues.apache.org/jira/browse/TS-4086 > Project: Traffic Server > Issue Type: Bug > Components: Logging >Reporter: Daniel Xu > Fix For: 6.1.0 > > > The minimum size to roll with is 10mb, but the documentation doesn't mention > this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-4058) Diagnostic logging doesn't work when TS is compiled and run w/ --with-user
[ https://issues.apache.org/jira/browse/TS-4058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Xu updated TS-4058: -- Summary: Diagnostic logging doesn't work when TS is compiled and run w/ --with-user (was: Logging doesn't work when TS is compiled and run w/ --with-user) > Diagnostic logging doesn't work when TS is compiled and run w/ --with-user > -- > > Key: TS-4058 > URL: https://issues.apache.org/jira/browse/TS-4058 > Project: Traffic Server > Issue Type: Bug > Components: Logging >Reporter: Daniel Xu >Assignee: Daniel Xu > Fix For: sometime > > > ie. we run this _without_ sudo. > traffic_cop output seems to point to permission errors that occur within > traffic_manager -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3110) Logs aren't rotating as specified
[
https://issues.apache.org/jira/browse/TS-3110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15062587#comment-15062587
]
Daniel Xu commented on TS-3110:
---
Tried but couldn't reproduce this issue.
> Logs aren't rotating as specified
> -
>
> Key: TS-3110
> URL: https://issues.apache.org/jira/browse/TS-3110
> Project: Traffic Server
> Issue Type: Bug
> Components: Logging
>Reporter: Bryan Call
>Assignee: Daniel Xu
> Fix For: sometime
>
>
> When setting the logs to rotate at a specified size AND time interval they
> are not rotating:
> {code}
> proxy.config.log.rolling_enabled 4
> proxy.config.log.rolling_interval_sec 300
> proxy.config.log.rolling_size_mb 10
> -rw-r--r-- 1 nobody nobody 15M Oct 2 13:54 squid.blog
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-4072) diagnostic log rolling races
[
https://issues.apache.org/jira/browse/TS-4072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15062701#comment-15062701
]
Daniel Xu commented on TS-4072:
---
We should be avoiding locks to fix this right? B/c of how high activity Diags is
> diagnostic log rolling races
>
>
> Key: TS-4072
> URL: https://issues.apache.org/jira/browse/TS-4072
> Project: Traffic Server
> Issue Type: Bug
> Components: Logging
>Reporter: James Peach
>Assignee: Daniel Xu
> Fix For: 6.2.0
>
>
> When diagnostic logs are rolled, {{Diags::diags_log}} is deleted and replaced
> with a new log object. Since the global {{diags}} points to a a single
> {{Diags}} object there is nothing to prevent a different thread logging
> through this object at the time it is deleted.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TS-4143) Validate host in GET URL
Daniel Xu created TS-4143: - Summary: Validate host in GET URL Key: TS-4143 URL: https://issues.apache.org/jira/browse/TS-4143 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Daniel Xu Host headers are currently validated but any potential hosts in the GET URL aren't -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-4058) Diagnostic logging doesn't work when TS is compiled and run w/ --with-user
[ https://issues.apache.org/jira/browse/TS-4058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15112752#comment-15112752 ] Daniel Xu commented on TS-4058: --- Looks like TS-4134 fixed this issue. > Diagnostic logging doesn't work when TS is compiled and run w/ --with-user > -- > > Key: TS-4058 > URL: https://issues.apache.org/jira/browse/TS-4058 > Project: Traffic Server > Issue Type: Bug > Components: Logging >Reporter: Daniel Xu >Assignee: Daniel Xu > Fix For: sometime > > > ie. we run this _without_ sudo. > traffic_cop output seems to point to permission errors that occur within > traffic_manager -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TS-4143) Validate host in GET URL
[ https://issues.apache.org/jira/browse/TS-4143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Xu resolved TS-4143. --- Resolution: Fixed > Validate host in GET URL > > > Key: TS-4143 > URL: https://issues.apache.org/jira/browse/TS-4143 > Project: Traffic Server > Issue Type: Bug > Components: Core >Reporter: Daniel Xu > Fix For: 6.2.0 > > > Host headers are currently validated but any potential hosts in the GET URL > aren't -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-4148) Add a squid log field for attempts to origin
Daniel Xu created TS-4148: - Summary: Add a squid log field for attempts to origin Key: TS-4148 URL: https://issues.apache.org/jira/browse/TS-4148 Project: Traffic Server Issue Type: Bug Components: Logging Reporter: Daniel Xu This field could be useful for traffic analysis. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-4148) Add a squid log field for attempts to origin
[ https://issues.apache.org/jira/browse/TS-4148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Xu updated TS-4148: -- Issue Type: Improvement (was: Bug) > Add a squid log field for attempts to origin > > > Key: TS-4148 > URL: https://issues.apache.org/jira/browse/TS-4148 > Project: Traffic Server > Issue Type: Improvement > Components: Logging >Reporter: Daniel Xu > > This field could be useful for traffic analysis. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-4148) Add a log field for connection attempts made to origin
[ https://issues.apache.org/jira/browse/TS-4148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Xu updated TS-4148: -- Summary: Add a log field for connection attempts made to origin (was: Add a log field for attempts made to origin) > Add a log field for connection attempts made to origin > -- > > Key: TS-4148 > URL: https://issues.apache.org/jira/browse/TS-4148 > Project: Traffic Server > Issue Type: Improvement > Components: Logging >Reporter: Daniel Xu > > This field could be useful for traffic analysis. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-4148) Add a log field for attempts to origin
[ https://issues.apache.org/jira/browse/TS-4148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Xu updated TS-4148: -- Summary: Add a log field for attempts to origin (was: Add a squid log field for attempts to origin) > Add a log field for attempts to origin > -- > > Key: TS-4148 > URL: https://issues.apache.org/jira/browse/TS-4148 > Project: Traffic Server > Issue Type: Improvement > Components: Logging >Reporter: Daniel Xu > > This field could be useful for traffic analysis. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-4148) Add a log field for attempts made to origin
[ https://issues.apache.org/jira/browse/TS-4148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Xu updated TS-4148: -- Summary: Add a log field for attempts made to origin (was: Add a log field for attempts to origin) > Add a log field for attempts made to origin > --- > > Key: TS-4148 > URL: https://issues.apache.org/jira/browse/TS-4148 > Project: Traffic Server > Issue Type: Improvement > Components: Logging >Reporter: Daniel Xu > > This field could be useful for traffic analysis. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-4159) ATS 6.1.0 does not log to stdout when not started from shell
[ https://issues.apache.org/jira/browse/TS-4159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15123986#comment-15123986 ] Daniel Xu commented on TS-4159: --- There was a change made in TS-306 that redirects stdout and stderr to traffic.out if TS is started by traffic_cop. traffic_cop adds the flags "-bind_stdout /opt/ats/var/log/traffic.out -bind_stderr /opt/ats/var/log/traffic.out" to the traffic_manager process, which then adds the same flags to the traffic_server process, which finally redirects stdout and stderr to traffic.out. > ATS 6.1.0 does not log to stdout when not started from shell > > > Key: TS-4159 > URL: https://issues.apache.org/jira/browse/TS-4159 > Project: Traffic Server > Issue Type: Bug > Components: Core >Reporter: Luca Bruno > Labels: regression > Fix For: 6.2.0 > > > I have a plugin that uses printf() to print some notice messages. Then my ATS > is started by systemd with just `ExecStart=/usr/bin/traffic_manager`. > With ATS 6.0.0 I could see the printf() from my plugin with journalctl. > That's because the stdout of the service is connected to the journal. > With ATS 6.1.0 the plugin output is not shown anymore with journalctl. > However, starting `traffic_manager` from the shell actually shows the plugin > output. > No file under the log directory contains the plugin output. > That makes me think there has been some change in 6.1.0 like: "if it's not a > tty, close stdout", or something like that. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (TS-4159) ATS 6.1.0 does not log to stdout when not started from shell
[ https://issues.apache.org/jira/browse/TS-4159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15123986#comment-15123986 ] Daniel Xu edited comment on TS-4159 at 1/29/16 7:01 PM: There was a change made in TS-306 that redirects stdout and stderr to traffic.out if TS is started by traffic_cop. traffic_cop adds the flags "-bind_stdout /opt/ats/var/log/traffic.out -bind_stderr /opt/ats/var/log/traffic.out" to the traffic_manager process, which then adds the same flags to the traffic_server process, which finally redirects stdout and stderr to traffic.out. A better alternative to printf()'ing would be to use any of the built in logging functions was (Author: danobi): There was a change made in TS-306 that redirects stdout and stderr to traffic.out if TS is started by traffic_cop. traffic_cop adds the flags "-bind_stdout /opt/ats/var/log/traffic.out -bind_stderr /opt/ats/var/log/traffic.out" to the traffic_manager process, which then adds the same flags to the traffic_server process, which finally redirects stdout and stderr to traffic.out. > ATS 6.1.0 does not log to stdout when not started from shell > > > Key: TS-4159 > URL: https://issues.apache.org/jira/browse/TS-4159 > Project: Traffic Server > Issue Type: Bug > Components: Core >Reporter: Luca Bruno > Labels: regression > Fix For: 6.2.0 > > > I have a plugin that uses printf() to print some notice messages. Then my ATS > is started by systemd with just `ExecStart=/usr/bin/traffic_manager`. > With ATS 6.0.0 I could see the printf() from my plugin with journalctl. > That's because the stdout of the service is connected to the journal. > With ATS 6.1.0 the plugin output is not shown anymore with journalctl. > However, starting `traffic_manager` from the shell actually shows the plugin > output. > No file under the log directory contains the plugin output. > That makes me think there has been some change in 6.1.0 like: "if it's not a > tty, close stdout", or something like that. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-4165) Logging breaks if changing log format
[
https://issues.apache.org/jira/browse/TS-4165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15124177#comment-15124177
]
Daniel Xu commented on TS-4165:
---
I can reproduce the described issue as well. I'm looking into it now
> Logging breaks if changing log format
> -
>
> Key: TS-4165
> URL: https://issues.apache.org/jira/browse/TS-4165
> Project: Traffic Server
> Issue Type: Bug
> Components: Logging
>Reporter: Eric Sproul
>Assignee: Daniel Xu
> Labels: regression
> Fix For: 6.2.0
>
>
> When upgrading to 6.1.0 from 5.3.2, I was also changing the format of a
> custom log, and that apparently caused all request logging to stop. In
> syslog I see this error:
> {code}
> {0x1} ERROR: Cannot roll log
> file /var/log/circonus/trafficserver/request.blog to fix log filename
> conflicts
> {code}
> Worked with folks on IRC, and ran under gdb, setting a breakpoint at
> {{BaseLogFile::roll}} and stepping through 3 times subsequently, before
> taking a backtrace:
> {code}
> (gdb) bt
> #0 BaseLogFile::roll (this=0x57f7550, interval_start=,
> interval_end=) at BaseLogFile.cc:119
> #1 0x006ebee0 in LogObjectManager::_solve_filename_conflicts
> (this=this@entry=0x36b9df8, log_object=log_object@entry=0xf17a90,
> maxConflicts=maxConflicts@entry=99) at LogObject.cc:1029
> #2 0x006ec619 in LogObjectManager::_manage_object (this=0x36b9df8,
> log_object=0xf17a90, is_api_object=false, maxConflicts=99)
> at LogObject.cc:894
> #3 0x006db8db in manage_object (maxConflicts=99, logObject=0xf17a90,
> this=0x36b9df8) at LogObject.h:394
> #4 LogConfig::read_xml_log_config (this=this@entry=0x36b9dd0) at
> LogConfig.cc:1468
> #5 0x006dda70 in setup_log_objects (this=0x36b9dd0) at
> LogConfig.cc:503
> #6 LogConfig::init (this=0x36b9dd0, prev_config=0x0) at LogConfig.cc:388
> #7 0x00815bcd in main ()
> (gdb) print *this
> $1 = {m_fp = 0x0, m_start_time = 1454090917, m_end_time = 0, m_bytes_written
> = 0, m_signature = 0, m_has_signature = true,
> m_name = { >> = {
> _r = 0x5809950 "/var/log/circonus/trafficserver/request.blog"}, data fields>},
> m_hostname = { >> =
> {_r = 0x10fa238 "lbva1"}, }, m_is_regfile = false,
> m_is_init = false, m_meta_info = 0x0}
> {code}
> [~amc] pointed out that {{m_is_regfile}} is false and that {{m_fp}} is null,
> and speculates that ATS might be assuming the file is open when it is not,
> and failing to roll the file. The one case where we would try to roll the
> files without them being open is when the log format is changing.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TS-4214) HttpSM debug message incorrect
Daniel Xu created TS-4214:
-
Summary: HttpSM debug message incorrect
Key: TS-4214
URL: https://issues.apache.org/jira/browse/TS-4214
Project: Traffic Server
Issue Type: Bug
Components: Logging
Reporter: Daniel Xu
The DebugSM() message in HttpSM::is_http_server_eos_truncation() has its format
string args flipped around. Right now it's:
{noformat}
server eos after [cl]. Expected [server_response_body_bytes]
{noformat}
It should be:
{noformat}
server eos after [server_response_body_bytes]. Expected [cl]
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-4214) Fix incorrect HttpSM debug message
[
https://issues.apache.org/jira/browse/TS-4214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Xu updated TS-4214:
--
Summary: Fix incorrect HttpSM debug message (was: HttpSM debug message
incorrect)
> Fix incorrect HttpSM debug message
> --
>
> Key: TS-4214
> URL: https://issues.apache.org/jira/browse/TS-4214
> Project: Traffic Server
> Issue Type: Bug
> Components: Logging
>Reporter: Daniel Xu
>
> The DebugSM() message in HttpSM::is_http_server_eos_truncation() has its
> format string args flipped around. Right now it's:
> {noformat}
> server eos after [cl]. Expected [server_response_body_bytes]
> {noformat}
> It should be:
> {noformat}
> server eos after [server_response_body_bytes]. Expected [cl]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (TS-5023) Allow diags.log and traffic.out to be rotated by size or time
[ https://issues.apache.org/jira/browse/TS-5023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Xu reassigned TS-5023: - Assignee: Daniel Xu > Allow diags.log and traffic.out to be rotated by size or time > - > > Key: TS-5023 > URL: https://issues.apache.org/jira/browse/TS-5023 > Project: Traffic Server > Issue Type: Improvement > Components: Logging >Reporter: Daniel Xu >Assignee: Daniel Xu > > Create a 3rd option for diags.log and traffic.out to be rolled by time OR > size. Currently access logs have this feature and diagnostic logs don't. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-5023) Allow diags.log and traffic.out to be rotated by size or time
Daniel Xu created TS-5023: - Summary: Allow diags.log and traffic.out to be rotated by size or time Key: TS-5023 URL: https://issues.apache.org/jira/browse/TS-5023 Project: Traffic Server Issue Type: Improvement Components: Logging Reporter: Daniel Xu Create a 3rd option for diags.log and traffic.out to be rolled by time OR size. Currently access logs have this feature and diagnostic logs don't. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-4400) TSProxyStateSet persist cache clearing across restart
[
https://issues.apache.org/jira/browse/TS-4400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Xu updated TS-4400:
--
Issue Type: Sub-task (was: Bug)
Parent: TS-4399
> TSProxyStateSet persist cache clearing across restart
> -
>
> Key: TS-4400
> URL: https://issues.apache.org/jira/browse/TS-4400
> Project: Traffic Server
> Issue Type: Sub-task
> Components: Management API
>Reporter: James Peach
>Assignee: Daniel Xu
> Fix For: 7.1.0
>
>
> If you use {{TSProxyStateSet}} and and pass the options to clear the cache,
> these options are persisted so that subsequent restarts will also clear the
> cache. This seems pretty bad and likely to cause accidents. The options
> should be one-shot.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TS-5053) const char **argv passed to TSPluginInit is not null terminated
Daniel Xu created TS-5053:
-
Summary: const char **argv passed to TSPluginInit is not null
terminated
Key: TS-5053
URL: https://issues.apache.org/jira/browse/TS-5053
Project: Traffic Server
Issue Type: Bug
Components: Plugins
Reporter: Daniel Xu
See title.
An example of an issue this can cause is that {{lib/ts/ink_args.cc}} actually
relies on **argv being null terminated. Interesting segfaults occur in plugins
usings the ATS argument parser.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (TS-5053) const char **argv passed to TSPluginInit is not null terminated
[
https://issues.apache.org/jira/browse/TS-5053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Xu reassigned TS-5053:
-
Assignee: Daniel Xu
> const char **argv passed to TSPluginInit is not null terminated
> ---
>
> Key: TS-5053
> URL: https://issues.apache.org/jira/browse/TS-5053
> Project: Traffic Server
> Issue Type: Bug
> Components: Plugins
>Reporter: Daniel Xu
>Assignee: Daniel Xu
>
> See title.
> An example of an issue this can cause is that {{lib/ts/ink_args.cc}} actually
> relies on **argv being null terminated. Interesting segfaults occur in
> plugins usings the ATS argument parser.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-5053) const char **argv passed to TSPluginInit is not null terminated
[
https://issues.apache.org/jira/browse/TS-5053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Xu updated TS-5053:
--
Description:
See title.
One example of an issue is that {{lib/ts/ink_args.cc}} actually relies on
**argv being null terminated. Interesting segfaults occur in plugins usings the
ATS argument parser.
was:
See title.
An example of an issue this can cause is that {{lib/ts/ink_args.cc}} actually
relies on **argv being null terminated. Interesting segfaults occur in plugins
usings the ATS argument parser.
> const char **argv passed to TSPluginInit is not null terminated
> ---
>
> Key: TS-5053
> URL: https://issues.apache.org/jira/browse/TS-5053
> Project: Traffic Server
> Issue Type: Bug
> Components: Plugins
>Reporter: Daniel Xu
>Assignee: Daniel Xu
>
> See title.
> One example of an issue is that {{lib/ts/ink_args.cc}} actually relies on
> **argv being null terminated. Interesting segfaults occur in plugins usings
> the ATS argument parser.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-5053) const char **argv passed to TSPluginInit is not null terminated
[
https://issues.apache.org/jira/browse/TS-5053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Xu updated TS-5053:
--
Description:
See title. Typically **argv is null terminated in other systems. And who are we
to question 1000 years of tradition?
One example of an issue is that {{lib/ts/ink_args.cc}} actually relies on
**argv being null terminated. Interesting segfaults occur in plugins usings the
ATS argument parser.
was:
See title. Typically **argv is null terminated. And who are we to question 1000
years of tradition?
One example of an issue is that {{lib/ts/ink_args.cc}} actually relies on
**argv being null terminated. Interesting segfaults occur in plugins usings the
ATS argument parser.
> const char **argv passed to TSPluginInit is not null terminated
> ---
>
> Key: TS-5053
> URL: https://issues.apache.org/jira/browse/TS-5053
> Project: Traffic Server
> Issue Type: Bug
> Components: Plugins
>Reporter: Daniel Xu
>Assignee: Daniel Xu
>
> See title. Typically **argv is null terminated in other systems. And who are
> we to question 1000 years of tradition?
> One example of an issue is that {{lib/ts/ink_args.cc}} actually relies on
> **argv being null terminated. Interesting segfaults occur in plugins usings
> the ATS argument parser.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-5053) const char **argv passed to TSPluginInit is not null terminated
[
https://issues.apache.org/jira/browse/TS-5053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Xu updated TS-5053:
--
Description:
See title. Typically **argv is null terminated. And who are we to question 1000
years of tradition?
One example of an issue is that {{lib/ts/ink_args.cc}} actually relies on
**argv being null terminated. Interesting segfaults occur in plugins usings the
ATS argument parser.
was:
See title.
One example of an issue is that {{lib/ts/ink_args.cc}} actually relies on
**argv being null terminated. Interesting segfaults occur in plugins usings the
ATS argument parser.
> const char **argv passed to TSPluginInit is not null terminated
> ---
>
> Key: TS-5053
> URL: https://issues.apache.org/jira/browse/TS-5053
> Project: Traffic Server
> Issue Type: Bug
> Components: Plugins
>Reporter: Daniel Xu
>Assignee: Daniel Xu
>
> See title. Typically **argv is null terminated. And who are we to question
> 1000 years of tradition?
> One example of an issue is that {{lib/ts/ink_args.cc}} actually relies on
> **argv being null terminated. Interesting segfaults occur in plugins usings
> the ATS argument parser.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TS-5056) Implement nonrecoverable error mechanism
Daniel Xu created TS-5056:
-
Summary: Implement nonrecoverable error mechanism
Key: TS-5056
URL: https://issues.apache.org/jira/browse/TS-5056
Project: Traffic Server
Issue Type: Improvement
Components: Manager
Reporter: Daniel Xu
There should be a mechanism for {{traffic_server}} to signal to
{{traffic_manager}} that {{traffic_server}} cannot be recovered with any amount
of restarting.
For example, if TS sees a bad log file, then no amount of restarting will fix
TS. Thus, it would be better for TM to just sit tight and wait for human
intervention.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (TS-5056) Implement nonrecoverable error mechanism
[
https://issues.apache.org/jira/browse/TS-5056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Xu reassigned TS-5056:
-
Assignee: Daniel Xu
> Implement nonrecoverable error mechanism
>
>
> Key: TS-5056
> URL: https://issues.apache.org/jira/browse/TS-5056
> Project: Traffic Server
> Issue Type: Improvement
> Components: Manager
>Reporter: Daniel Xu
>Assignee: Daniel Xu
> Time Spent: 10m
> Remaining Estimate: 0h
>
> There should be a mechanism for {{traffic_server}} to signal to
> {{traffic_manager}} that {{traffic_server}} cannot be recovered with any
> amount of restarting.
> For example, if TS sees a bad log file, then no amount of restarting will fix
> TS. Thus, it would be better for TM to just sit tight and wait for human
> intervention.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-5056) Implement nonrecoverable error mechanism
[
https://issues.apache.org/jira/browse/TS-5056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15703173#comment-15703173
]
Daniel Xu commented on TS-5056:
---
I think {{Emergency()}} should only be called in very obvious and dire
circumstances. In the worst case, it should save some CPU cycles.
We're currently tracking a problem at Y! where it would be useful to have TM
not try to constantly restart TS. The new {{Emergency()}} call should be put to
use soon^tm.
> Implement nonrecoverable error mechanism
>
>
> Key: TS-5056
> URL: https://issues.apache.org/jira/browse/TS-5056
> Project: Traffic Server
> Issue Type: Improvement
> Components: Manager
>Reporter: Daniel Xu
>Assignee: Daniel Xu
> Fix For: 7.1.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> There should be a mechanism for {{traffic_server}} to signal to
> {{traffic_manager}} that {{traffic_server}} cannot be recovered with any
> amount of restarting.
> For example, if TS sees a bad log file, then no amount of restarting will fix
> TS. Thus, it would be better for TM to just sit tight and wait for human
> intervention.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-4426) BaseLogFile::open_file stdout stderr bind error
[ https://issues.apache.org/jira/browse/TS-4426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15709065#comment-15709065 ] Daniel Xu commented on TS-4426: --- I'm not sure I fully understand what you're describing. Is this related to TS-4416? See my comment there. > BaseLogFile::open_file stdout stderr bind error > > > Key: TS-4426 > URL: https://issues.apache.org/jira/browse/TS-4426 > Project: Traffic Server > Issue Type: Bug > Components: Logging, Manager >Reporter: Song CW >Assignee: Daniel Xu > Fix For: 7.1.0 > > > The condition "!strcmp(m_name.get(), "stdout")" will never be true when we > start manager with --bind_stderr (--bind_stdout) args, because the name of > BaseLogFile struct we set in set_stdout_output is --bind_stdout --bind_stderr. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-4416) process_args_ex parse error
[
https://issues.apache.org/jira/browse/TS-4416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15709055#comment-15709055
]
Daniel Xu commented on TS-4416:
---
[~scwsy00] Are you starting the {{traffic_server}} binary like this: {{sudo
./traffic_server --bind_stdout --bind_stderr /path/to/log}}? It's not obvious
to me why it would be happening otherwise.
If you could attach a coredump (if ATS crashed), that would be helpful.
> process_args_ex parse error
> ---
>
> Key: TS-4416
> URL: https://issues.apache.org/jira/browse/TS-4416
> Project: Traffic Server
> Issue Type: Bug
> Components: Tools
>Reporter: Song CW
>Assignee: Daniel Xu
> Fix For: 7.1.0
>
> Attachments: (gdb)
>
>
> According to TS-4399, I found something strange in process_args_ex when I
> starting manager with --bind_stderr --bind_stdout args!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-4636) traffic.out is open too many times
[
https://issues.apache.org/jira/browse/TS-4636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15709516#comment-15709516
]
Daniel Xu commented on TS-4636:
---
I haven't done any deep digging, but my hunch is that it has to do with
{{proxy/Main.cc::bind_outputs}}. That function is opening {{traffic.out}} and
using {{dup2}} to to redirect stdout & stderr to {{traffic.out}}.
Correct me if I'm wrong b/c I'm not sure how dup2 is implemented w/ regards to
opening & closing file descriptors.
> traffic.out is open too many times
> --
>
> Key: TS-4636
> URL: https://issues.apache.org/jira/browse/TS-4636
> Project: Traffic Server
> Issue Type: Bug
> Components: Core, Logging
>Reporter: James Peach
>Assignee: Daniel Xu
> Fix For: sometime
>
>
> Looks like something is wrong with {{traffic.out}}. I am expecting that this
> shold only be open twice (for stdout and stderr).
> {noformat}
> traffic_s 12272 nmadmin0w CHR1,3 0t0 1051
> /dev/null
> traffic_s 12272 nmadmin1w REG 202,172377 524555
> /n/log/trafficserver/traffic.out
> traffic_s 12272 nmadmin2w REG 202,172377 524555
> /n/log/trafficserver/traffic.out
> traffic_s 12272 nmadmin3r DIR 202,1 40962 /
> traffic_s 12272 nmadmin4u REG 202,1 3839 524557
> /n/log/trafficserver/manager.log
> traffic_s 12272 nmadmin5u REG 202,172377 524555
> /n/log/trafficserver/traffic.out
> traffic_s 12272 nmadmin6u 0,90 6384
> anon_inode
> traffic_s 12272 nmadmin7u REG 202,172377 524555
> /n/log/trafficserver/traffic.out
> traffic_s 12272 nmadmin8u 0,90 6384
> anon_inode
> traffic_s 12272 nmadmin9u IPv4 19233316 0t0 TCP *:80
> (LISTEN)
> traffic_s 12272 nmadmin 10u IPv4 19233317 0t0 TCP
> *:443 (LISTEN)
> traffic_s 12272 nmadmin 11u 0,90 6384
> anon_inode
> traffic_s 12272 nmadmin 12u 0,90 6384
> anon_inode
> traffic_s 12272 nmadmin 13u unix 0x8801e2aaf080 0t0 19233322
> socket
> traffic_s 12272 nmadmin 14u REG 202,172377 524555
> /n/log/trafficserver/traffic.out
> traffic_s 12272 nmadmin 15u REG 202,172377 524555
> /n/log/trafficserver/traffic.out
> traffic_s 12272 nmadmin 16u unix 0x8800d9e63c00 0t0 19233956
> socket
> {noformat}
> {noformat}
> [root@qa1 ~]# lsof -P -p $(pidof traffic_server) | grep traffic.out
> [ET_NET 2317 nobody1u REG 202,1542101711082
> /opt/ats/var/log/trafficserver/traffic.out
> [ET_NET 2317 nobody2u REG 202,1542101711082
> /opt/ats/var/log/trafficserver/traffic.out
> [ET_NET 2317 nobody5u REG 202,1542101711082
> /opt/ats/var/log/trafficserver/traffic.out
> [ET_NET 2317 nobody7u REG 202,1542101711082
> /opt/ats/var/log/trafficserver/traffic.out
> [ET_NET 2317 nobody 17u REG 202,1542101711082
> /opt/ats/var/log/trafficserver/traffic.out
> [ET_NET 2317 nobody 21u REG 202,1542101711082
> /opt/ats/var/log/trafficserver/traffic.out
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (TS-5070) Add configuration variables to set file permissions for diags.log & traffic.out
[
https://issues.apache.org/jira/browse/TS-5070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Xu reassigned TS-5070:
-
Assignee: Daniel Xu
> Add configuration variables to set file permissions for diags.log &
> traffic.out
> ---
>
> Key: TS-5070
> URL: https://issues.apache.org/jira/browse/TS-5070
> Project: Traffic Server
> Issue Type: Improvement
> Components: Logging
>Reporter: Daniel Xu
>Assignee: Daniel Xu
>
> It would be useful to be able to control file permissions for {{diags.log}}
> and {{traffic.out}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TS-5070) Add configuration variables to set file permissions for diags.log & traffic.out
Daniel Xu created TS-5070:
-
Summary: Add configuration variables to set file permissions for
diags.log & traffic.out
Key: TS-5070
URL: https://issues.apache.org/jira/browse/TS-5070
Project: Traffic Server
Issue Type: Improvement
Components: Logging
Reporter: Daniel Xu
It would be useful to be able to control file permissions for {{diags.log}} and
{{traffic.out}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-5070) Add configuration variables to set file permissions for diags.log & traffic.out
[
https://issues.apache.org/jira/browse/TS-5070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15723405#comment-15723405
]
Daniel Xu commented on TS-5070:
---
Currently running into issues with POSIX capability stuff.
The problem is that {{traffic.out}}, unlike {{squid.blog}}, is created before
ATS drops superuser status. Thus, we cannot use a traditional {{chmod(2)}} on
{{traffic.out}} since {{traffic.out}} is owned by root when we want to change
it as {{nobody}}.
I think the trick here is to use the {{CAP_FOWNER}} capability to bypass
permission checks.
> Add configuration variables to set file permissions for diags.log &
> traffic.out
> ---
>
> Key: TS-5070
> URL: https://issues.apache.org/jira/browse/TS-5070
> Project: Traffic Server
> Issue Type: Improvement
> Components: Logging
>Reporter: Daniel Xu
>Assignee: Daniel Xu
>
> It would be useful to be able to control file permissions for {{diags.log}}
> and {{traffic.out}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TS-5084) Make logcat follow file rotation
Daniel Xu created TS-5084:
-
Summary: Make logcat follow file rotation
Key: TS-5084
URL: https://issues.apache.org/jira/browse/TS-5084
Project: Traffic Server
Issue Type: Improvement
Components: Logging
Reporter: Daniel Xu
The {{traffic_logcat}} tool does not follow squid.blog if it is rotated. It
would be nice if the tool would follow the log.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (TS-5084) Make logcat follow file rotation
[
https://issues.apache.org/jira/browse/TS-5084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Xu reassigned TS-5084:
-
Assignee: Daniel Xu
> Make logcat follow file rotation
>
>
> Key: TS-5084
> URL: https://issues.apache.org/jira/browse/TS-5084
> Project: Traffic Server
> Issue Type: Improvement
> Components: Logging
>Reporter: Daniel Xu
>Assignee: Daniel Xu
>
> The {{traffic_logcat}} tool does not follow squid.blog if it is rotated. It
> would be nice if the tool would follow the log.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-5084) Make logcat follow file rotation
[
https://issues.apache.org/jira/browse/TS-5084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Xu updated TS-5084:
--
Description: The {{traffic_logcat}} tool does not follow {{squid.blog}} if
it is rotated. This is still occurring even when {{traffic_logcat}} is run with
{{-f}} It would be nice if the tool would follow the log. (was: The
{{traffic_logcat}} tool does not follow squid.blog if it is rotated. It would
be nice if the tool would follow the log.)
> Make logcat follow file rotation
>
>
> Key: TS-5084
> URL: https://issues.apache.org/jira/browse/TS-5084
> Project: Traffic Server
> Issue Type: Improvement
> Components: Logging
>Reporter: Daniel Xu
>Assignee: Daniel Xu
>
> The {{traffic_logcat}} tool does not follow {{squid.blog}} if it is rotated.
> This is still occurring even when {{traffic_logcat}} is run with {{-f}} It
> would be nice if the tool would follow the log.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (TS-5085) `posix_fadvise` is incorrectly used in traffic_logcat
[
https://issues.apache.org/jira/browse/TS-5085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Xu reassigned TS-5085:
-
Assignee: Daniel Xu
> `posix_fadvise` is incorrectly used in traffic_logcat
> -
>
> Key: TS-5085
> URL: https://issues.apache.org/jira/browse/TS-5085
> Project: Traffic Server
> Issue Type: Bug
> Components: Logging
>Reporter: Daniel Xu
>Assignee: Daniel Xu
>
> {{traffic_logcat}} is currently using {{posix_fadvise}} the exact opposite
> way it should be used. It's currently telling the kernel it doesn't need
> anything in this file and then immediately proceeds to read everything in the
> file anyways.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TS-5085) `posix_fadvise` is incorrectly used in traffic_logcat
Daniel Xu created TS-5085:
-
Summary: `posix_fadvise` is incorrectly used in traffic_logcat
Key: TS-5085
URL: https://issues.apache.org/jira/browse/TS-5085
Project: Traffic Server
Issue Type: Bug
Components: Logging
Reporter: Daniel Xu
{{traffic_logcat}} is currently using {{posix_fadvise}} the exact opposite way
it should be used. It's currently telling the kernel it doesn't need anything
in this file and then immediately proceeds to read everything in the file
anyways.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-4636) traffic.out is open too many times
[
https://issues.apache.org/jira/browse/TS-4636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15743482#comment-15743482
]
Daniel Xu commented on TS-4636:
---
Update: did more digging. If you run the {{traffic_server}} binary alone, there
are 4 copies of {{traffic.out}} open. It looks like these are all open for good
reason. 1 fd is for the stdout BaseLogFile; 1 fd is for the stderr BaseLogFile;
1 fd is for the duplicated STDERR_FILENO; 1 fd is for the duplicated
STDOUT_FILENO. Although this could maybe be improved, I don't see any great
reason to spend time doing it.
However, when you run the {{trafficserver}} script, {{traffic_server}} has 6
files open. Still need to dig more. Will continue Wednesday. My hunch right now
is the initial non-records using Diags object is using dup2 on
STD{ERR,OUT}_FILENO.
> traffic.out is open too many times
> --
>
> Key: TS-4636
> URL: https://issues.apache.org/jira/browse/TS-4636
> Project: Traffic Server
> Issue Type: Bug
> Components: Core, Logging
>Reporter: James Peach
>Assignee: Daniel Xu
> Fix For: sometime
>
>
> Looks like something is wrong with {{traffic.out}}. I am expecting that this
> shold only be open twice (for stdout and stderr).
> {noformat}
> traffic_s 12272 nmadmin0w CHR1,3 0t0 1051
> /dev/null
> traffic_s 12272 nmadmin1w REG 202,172377 524555
> /n/log/trafficserver/traffic.out
> traffic_s 12272 nmadmin2w REG 202,172377 524555
> /n/log/trafficserver/traffic.out
> traffic_s 12272 nmadmin3r DIR 202,1 40962 /
> traffic_s 12272 nmadmin4u REG 202,1 3839 524557
> /n/log/trafficserver/manager.log
> traffic_s 12272 nmadmin5u REG 202,172377 524555
> /n/log/trafficserver/traffic.out
> traffic_s 12272 nmadmin6u 0,90 6384
> anon_inode
> traffic_s 12272 nmadmin7u REG 202,172377 524555
> /n/log/trafficserver/traffic.out
> traffic_s 12272 nmadmin8u 0,90 6384
> anon_inode
> traffic_s 12272 nmadmin9u IPv4 19233316 0t0 TCP *:80
> (LISTEN)
> traffic_s 12272 nmadmin 10u IPv4 19233317 0t0 TCP
> *:443 (LISTEN)
> traffic_s 12272 nmadmin 11u 0,90 6384
> anon_inode
> traffic_s 12272 nmadmin 12u 0,90 6384
> anon_inode
> traffic_s 12272 nmadmin 13u unix 0x8801e2aaf080 0t0 19233322
> socket
> traffic_s 12272 nmadmin 14u REG 202,172377 524555
> /n/log/trafficserver/traffic.out
> traffic_s 12272 nmadmin 15u REG 202,172377 524555
> /n/log/trafficserver/traffic.out
> traffic_s 12272 nmadmin 16u unix 0x8800d9e63c00 0t0 19233956
> socket
> {noformat}
> {noformat}
> [root@qa1 ~]# lsof -P -p $(pidof traffic_server) | grep traffic.out
> [ET_NET 2317 nobody1u REG 202,1542101711082
> /opt/ats/var/log/trafficserver/traffic.out
> [ET_NET 2317 nobody2u REG 202,1542101711082
> /opt/ats/var/log/trafficserver/traffic.out
> [ET_NET 2317 nobody5u REG 202,1542101711082
> /opt/ats/var/log/trafficserver/traffic.out
> [ET_NET 2317 nobody7u REG 202,1542101711082
> /opt/ats/var/log/trafficserver/traffic.out
> [ET_NET 2317 nobody 17u REG 202,1542101711082
> /opt/ats/var/log/trafficserver/traffic.out
> [ET_NET 2317 nobody 21u REG 202,1542101711082
> /opt/ats/var/log/trafficserver/traffic.out
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (TS-4636) traffic.out is open too many times
[
https://issues.apache.org/jira/browse/TS-4636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15743482#comment-15743482
]
Daniel Xu edited comment on TS-4636 at 12/12/16 11:19 PM:
--
Update: did more digging. If you run the {{traffic_server}} binary alone, there
are 4 copies of {{traffic.out}} open. It looks like these are all open for good
reason. 1 fd is for the stdout BaseLogFile; 1 fd is for the stderr BaseLogFile;
1 fd is for the duplicated STDERR_FILENO; 1 fd is for the duplicated
STDOUT_FILENO. Although this could maybe be improved, I don't see any great
reason to spend time doing it.
However, when you run the {{trafficserver}} script, {{traffic_server}} has 6
files open. Still need to dig more. Will continue Wednesday. My hunch right now
is the initial non-records Diags object is using dup2 on STD{ERR,OUT}_FILENO.
was (Author: danobi):
Update: did more digging. If you run the {{traffic_server}} binary alone, there
are 4 copies of {{traffic.out}} open. It looks like these are all open for good
reason. 1 fd is for the stdout BaseLogFile; 1 fd is for the stderr BaseLogFile;
1 fd is for the duplicated STDERR_FILENO; 1 fd is for the duplicated
STDOUT_FILENO. Although this could maybe be improved, I don't see any great
reason to spend time doing it.
However, when you run the {{trafficserver}} script, {{traffic_server}} has 6
files open. Still need to dig more. Will continue Wednesday. My hunch right now
is the initial non-records using Diags object is using dup2 on
STD{ERR,OUT}_FILENO.
> traffic.out is open too many times
> --
>
> Key: TS-4636
> URL: https://issues.apache.org/jira/browse/TS-4636
> Project: Traffic Server
> Issue Type: Bug
> Components: Core, Logging
>Reporter: James Peach
>Assignee: Daniel Xu
> Fix For: sometime
>
>
> Looks like something is wrong with {{traffic.out}}. I am expecting that this
> shold only be open twice (for stdout and stderr).
> {noformat}
> traffic_s 12272 nmadmin0w CHR1,3 0t0 1051
> /dev/null
> traffic_s 12272 nmadmin1w REG 202,172377 524555
> /n/log/trafficserver/traffic.out
> traffic_s 12272 nmadmin2w REG 202,172377 524555
> /n/log/trafficserver/traffic.out
> traffic_s 12272 nmadmin3r DIR 202,1 40962 /
> traffic_s 12272 nmadmin4u REG 202,1 3839 524557
> /n/log/trafficserver/manager.log
> traffic_s 12272 nmadmin5u REG 202,172377 524555
> /n/log/trafficserver/traffic.out
> traffic_s 12272 nmadmin6u 0,90 6384
> anon_inode
> traffic_s 12272 nmadmin7u REG 202,172377 524555
> /n/log/trafficserver/traffic.out
> traffic_s 12272 nmadmin8u 0,90 6384
> anon_inode
> traffic_s 12272 nmadmin9u IPv4 19233316 0t0 TCP *:80
> (LISTEN)
> traffic_s 12272 nmadmin 10u IPv4 19233317 0t0 TCP
> *:443 (LISTEN)
> traffic_s 12272 nmadmin 11u 0,90 6384
> anon_inode
> traffic_s 12272 nmadmin 12u 0,90 6384
> anon_inode
> traffic_s 12272 nmadmin 13u unix 0x8801e2aaf080 0t0 19233322
> socket
> traffic_s 12272 nmadmin 14u REG 202,172377 524555
> /n/log/trafficserver/traffic.out
> traffic_s 12272 nmadmin 15u REG 202,172377 524555
> /n/log/trafficserver/traffic.out
> traffic_s 12272 nmadmin 16u unix 0x8800d9e63c00 0t0 19233956
> socket
> {noformat}
> {noformat}
> [root@qa1 ~]# lsof -P -p $(pidof traffic_server) | grep traffic.out
> [ET_NET 2317 nobody1u REG 202,1542101711082
> /opt/ats/var/log/trafficserver/traffic.out
> [ET_NET 2317 nobody2u REG 202,1542101711082
> /opt/ats/var/log/trafficserver/traffic.out
> [ET_NET 2317 nobody5u REG 202,1542101711082
> /opt/ats/var/log/trafficserver/traffic.out
> [ET_NET 2317 nobody7u REG 202,1542101711082
> /opt/ats/var/log/trafficserver/traffic.out
> [ET_NET 2317 nobody 17u REG 202,1542101711082
> /opt/ats/var/log/trafficserver/traffic.out
> [ET_NET 2317 nobody 21u REG 202,1542101711082
> /opt/ats/var/log/trafficserver/traffic.out
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (TS-4636) traffic.out is open too many times
[
https://issues.apache.org/jira/browse/TS-4636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15743482#comment-15743482
]
Daniel Xu edited comment on TS-4636 at 12/12/16 11:22 PM:
--
Update: did more digging. If you run the {{traffic_server}} binary alone, there
are 4 copies of {{traffic.out}} open. It looks like these are all open for good
reason. 1 fd is for the stdout BaseLogFile; 1 fd is for the stderr BaseLogFile;
1 fd is for the duplicated STDERR_FILENO; 1 fd is for the duplicated
STDOUT_FILENO. Although this could maybe be improved, I don't see any great
reason to spend time doing it.
However, when you run the {{trafficserver}} script, {{traffic_server}} has 6
files open. Still need to dig more. Will continue Wednesday. My hunch right now
is the initial non-records Diags object is using dup2 on
{{STD{ERR,OUT}_FILENO}}.
was (Author: danobi):
Update: did more digging. If you run the {{traffic_server}} binary alone, there
are 4 copies of {{traffic.out}} open. It looks like these are all open for good
reason. 1 fd is for the stdout BaseLogFile; 1 fd is for the stderr BaseLogFile;
1 fd is for the duplicated STDERR_FILENO; 1 fd is for the duplicated
STDOUT_FILENO. Although this could maybe be improved, I don't see any great
reason to spend time doing it.
However, when you run the {{trafficserver}} script, {{traffic_server}} has 6
files open. Still need to dig more. Will continue Wednesday. My hunch right now
is the initial non-records Diags object is using dup2 on STD{ERR,OUT}_FILENO.
> traffic.out is open too many times
> --
>
> Key: TS-4636
> URL: https://issues.apache.org/jira/browse/TS-4636
> Project: Traffic Server
> Issue Type: Bug
> Components: Core, Logging
>Reporter: James Peach
>Assignee: Daniel Xu
> Fix For: sometime
>
>
> Looks like something is wrong with {{traffic.out}}. I am expecting that this
> shold only be open twice (for stdout and stderr).
> {noformat}
> traffic_s 12272 nmadmin0w CHR1,3 0t0 1051
> /dev/null
> traffic_s 12272 nmadmin1w REG 202,172377 524555
> /n/log/trafficserver/traffic.out
> traffic_s 12272 nmadmin2w REG 202,172377 524555
> /n/log/trafficserver/traffic.out
> traffic_s 12272 nmadmin3r DIR 202,1 40962 /
> traffic_s 12272 nmadmin4u REG 202,1 3839 524557
> /n/log/trafficserver/manager.log
> traffic_s 12272 nmadmin5u REG 202,172377 524555
> /n/log/trafficserver/traffic.out
> traffic_s 12272 nmadmin6u 0,90 6384
> anon_inode
> traffic_s 12272 nmadmin7u REG 202,172377 524555
> /n/log/trafficserver/traffic.out
> traffic_s 12272 nmadmin8u 0,90 6384
> anon_inode
> traffic_s 12272 nmadmin9u IPv4 19233316 0t0 TCP *:80
> (LISTEN)
> traffic_s 12272 nmadmin 10u IPv4 19233317 0t0 TCP
> *:443 (LISTEN)
> traffic_s 12272 nmadmin 11u 0,90 6384
> anon_inode
> traffic_s 12272 nmadmin 12u 0,90 6384
> anon_inode
> traffic_s 12272 nmadmin 13u unix 0x8801e2aaf080 0t0 19233322
> socket
> traffic_s 12272 nmadmin 14u REG 202,172377 524555
> /n/log/trafficserver/traffic.out
> traffic_s 12272 nmadmin 15u REG 202,172377 524555
> /n/log/trafficserver/traffic.out
> traffic_s 12272 nmadmin 16u unix 0x8800d9e63c00 0t0 19233956
> socket
> {noformat}
> {noformat}
> [root@qa1 ~]# lsof -P -p $(pidof traffic_server) | grep traffic.out
> [ET_NET 2317 nobody1u REG 202,1542101711082
> /opt/ats/var/log/trafficserver/traffic.out
> [ET_NET 2317 nobody2u REG 202,1542101711082
> /opt/ats/var/log/trafficserver/traffic.out
> [ET_NET 2317 nobody5u REG 202,1542101711082
> /opt/ats/var/log/trafficserver/traffic.out
> [ET_NET 2317 nobody7u REG 202,1542101711082
> /opt/ats/var/log/trafficserver/traffic.out
> [ET_NET 2317 nobody 17u REG 202,1542101711082
> /opt/ats/var/log/trafficserver/traffic.out
> [ET_NET 2317 nobody 21u REG 202,1542101711082
> /opt/ats/var/log/trafficserver/traffic.out
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-4636) traffic.out is open too many times
[
https://issues.apache.org/jira/browse/TS-4636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15748956#comment-15748956
]
Daniel Xu commented on TS-4636:
---
Figured it out. The reason {{traffic_server}} opens {{traffic.out}} 6x is
because TS inherits 4 FDs from {{traffic_manager}}. TS then overrides stdout
and stderr while opening 2 more FDs. That makes 6 total.
As far as I know, this could be improved/fixed (FD_CLOEXEC) but I don't see any
reason to spend time doing it. Let me know if there's a good argument,
[~jpe...@apache.org].
> traffic.out is open too many times
> --
>
> Key: TS-4636
> URL: https://issues.apache.org/jira/browse/TS-4636
> Project: Traffic Server
> Issue Type: Bug
> Components: Core, Logging
>Reporter: James Peach
>Assignee: Daniel Xu
> Fix For: sometime
>
>
> Looks like something is wrong with {{traffic.out}}. I am expecting that this
> shold only be open twice (for stdout and stderr).
> {noformat}
> traffic_s 12272 nmadmin0w CHR1,3 0t0 1051
> /dev/null
> traffic_s 12272 nmadmin1w REG 202,172377 524555
> /n/log/trafficserver/traffic.out
> traffic_s 12272 nmadmin2w REG 202,172377 524555
> /n/log/trafficserver/traffic.out
> traffic_s 12272 nmadmin3r DIR 202,1 40962 /
> traffic_s 12272 nmadmin4u REG 202,1 3839 524557
> /n/log/trafficserver/manager.log
> traffic_s 12272 nmadmin5u REG 202,172377 524555
> /n/log/trafficserver/traffic.out
> traffic_s 12272 nmadmin6u 0,90 6384
> anon_inode
> traffic_s 12272 nmadmin7u REG 202,172377 524555
> /n/log/trafficserver/traffic.out
> traffic_s 12272 nmadmin8u 0,90 6384
> anon_inode
> traffic_s 12272 nmadmin9u IPv4 19233316 0t0 TCP *:80
> (LISTEN)
> traffic_s 12272 nmadmin 10u IPv4 19233317 0t0 TCP
> *:443 (LISTEN)
> traffic_s 12272 nmadmin 11u 0,90 6384
> anon_inode
> traffic_s 12272 nmadmin 12u 0,90 6384
> anon_inode
> traffic_s 12272 nmadmin 13u unix 0x8801e2aaf080 0t0 19233322
> socket
> traffic_s 12272 nmadmin 14u REG 202,172377 524555
> /n/log/trafficserver/traffic.out
> traffic_s 12272 nmadmin 15u REG 202,172377 524555
> /n/log/trafficserver/traffic.out
> traffic_s 12272 nmadmin 16u unix 0x8800d9e63c00 0t0 19233956
> socket
> {noformat}
> {noformat}
> [root@qa1 ~]# lsof -P -p $(pidof traffic_server) | grep traffic.out
> [ET_NET 2317 nobody1u REG 202,1542101711082
> /opt/ats/var/log/trafficserver/traffic.out
> [ET_NET 2317 nobody2u REG 202,1542101711082
> /opt/ats/var/log/trafficserver/traffic.out
> [ET_NET 2317 nobody5u REG 202,1542101711082
> /opt/ats/var/log/trafficserver/traffic.out
> [ET_NET 2317 nobody7u REG 202,1542101711082
> /opt/ats/var/log/trafficserver/traffic.out
> [ET_NET 2317 nobody 17u REG 202,1542101711082
> /opt/ats/var/log/trafficserver/traffic.out
> [ET_NET 2317 nobody 21u REG 202,1542101711082
> /opt/ats/var/log/trafficserver/traffic.out
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (TS-5097) Validate plugin argument count
[ https://issues.apache.org/jira/browse/TS-5097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Xu reassigned TS-5097: - Assignee: Daniel Xu > Validate plugin argument count > -- > > Key: TS-5097 > URL: https://issues.apache.org/jira/browse/TS-5097 > Project: Traffic Server > Issue Type: Bug > Components: Plugins >Reporter: Daniel Xu >Assignee: Daniel Xu > > The plugin initialization code in proxy/Plugin.cc is hard coded to have a > maximum of 64 plugin arguments. However, the code isn't validating that the > provided list of arguments is < 64 in count. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-5097) Validate plugin argument count
Daniel Xu created TS-5097: - Summary: Validate plugin argument count Key: TS-5097 URL: https://issues.apache.org/jira/browse/TS-5097 Project: Traffic Server Issue Type: Bug Components: Plugins Reporter: Daniel Xu The plugin initialization code in proxy/Plugin.cc is hard coded to have a maximum of 64 plugin arguments. However, the code isn't validating that the provided list of arguments is < 64 in count. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
