[jira] [Updated] (TS-1606) Log buffers are not flushed periodically when TS is launched with NO_REMOTE_MANAGEMENT flag
[
https://issues.apache.org/jira/browse/TS-1606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yakov Markovitch updated TS-1606:
-
Attachment: trafficserver-periodic-tasks.patch
Better patch, prevents duplicate periodic tasks initialization.
> Log buffers are not flushed periodically when TS is launched with
> NO_REMOTE_MANAGEMENT flag
> ---
>
> Key: TS-1606
> URL: https://issues.apache.org/jira/browse/TS-1606
> Project: Traffic Server
> Issue Type: Bug
> Components: Logging
>Affects Versions: 3.3.0, 3.2.0
>Reporter: Yakov Markovitch
>Assignee: Leif Hedstrom
> Fix For: 3.3.1
>
> Attachments: trafficserver-periodic-tasks.patch
>
>
> When TS binary is launched with NO_REMOTE_MANAGEMENT flag (e.g., when
> launched not as a daemon but directly - this is extremely convenient for
> debugging), the PeriodicWakeup event is not scheduled.
> As a result, Log::flush_thread_main() does not wake up periodically, but only
> on log buffer overflow. Coupled with a horribly wrong activation check in
> Log::flush_thread_main():
> {code}
> if (now > last_time) {
> if ((now % PERIODIC_TASKS_INTERVAL) == 0) {
> // We run only when waken up at the moment which is exact
> // multiple of PERIODIC_TASKS_INTERVAL!
> {code}
> this leads to that probability of any log output is low.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1606) Log buffers are not flushed periodically when TS is launched with NO_REMOTE_MANAGEMENT flag
[
https://issues.apache.org/jira/browse/TS-1606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yakov Markovitch updated TS-1606:
-
Attachment: (was: trafficserver-periodic-tasks.patch)
> Log buffers are not flushed periodically when TS is launched with
> NO_REMOTE_MANAGEMENT flag
> ---
>
> Key: TS-1606
> URL: https://issues.apache.org/jira/browse/TS-1606
> Project: Traffic Server
> Issue Type: Bug
> Components: Logging
>Affects Versions: 3.3.0, 3.2.0
>Reporter: Yakov Markovitch
>Assignee: Leif Hedstrom
> Fix For: 3.3.1
>
>
> When TS binary is launched with NO_REMOTE_MANAGEMENT flag (e.g., when
> launched not as a daemon but directly - this is extremely convenient for
> debugging), the PeriodicWakeup event is not scheduled.
> As a result, Log::flush_thread_main() does not wake up periodically, but only
> on log buffer overflow. Coupled with a horribly wrong activation check in
> Log::flush_thread_main():
> {code}
> if (now > last_time) {
> if ((now % PERIODIC_TASKS_INTERVAL) == 0) {
> // We run only when waken up at the moment which is exact
> // multiple of PERIODIC_TASKS_INTERVAL!
> {code}
> this leads to that probability of any log output is low.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1606) Log buffers are not flushed periodically when TS is launched with NO_REMOTE_MANAGEMENT flag
[
https://issues.apache.org/jira/browse/TS-1606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yakov Markovitch updated TS-1606:
-
Attachment: trafficserver-periodic-tasks.patch
This patch both fixes the bug and removes some dead code in logging
initialization.
> Log buffers are not flushed periodically when TS is launched with
> NO_REMOTE_MANAGEMENT flag
> ---
>
> Key: TS-1606
> URL: https://issues.apache.org/jira/browse/TS-1606
> Project: Traffic Server
> Issue Type: Bug
> Components: Logging
>Affects Versions: 3.3.0, 3.2.0
>Reporter: Yakov Markovitch
> Attachments: trafficserver-periodic-tasks.patch
>
>
> When TS binary is launched with NO_REMOTE_MANAGEMENT flag (e.g., when
> launched not as a daemon but directly - this is extremely convenient for
> debugging), the PeriodicWakeup event is not scheduled.
> As a result, Log::flush_thread_main() does not wake up periodically, but only
> on log buffer overflow. Coupled with a horribly wrong activation check in
> Log::flush_thread_main():
> {code}
> if (now > last_time) {
> if ((now % PERIODIC_TASKS_INTERVAL) == 0) {
> // We run only when waken up at the moment which is exact
> // multiple of PERIODIC_TASKS_INTERVAL!
> {code}
> this leads to that probability of any log output is low.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-1606) Log buffers are not flushed periodically when TS is launched with NO_REMOTE_MANAGEMENT flag
Yakov Markovitch created TS-1606:
Summary: Log buffers are not flushed periodically when TS is
launched with NO_REMOTE_MANAGEMENT flag
Key: TS-1606
URL: https://issues.apache.org/jira/browse/TS-1606
Project: Traffic Server
Issue Type: Bug
Components: Logging
Reporter: Yakov Markovitch
When TS binary is launched with NO_REMOTE_MANAGEMENT flag (e.g., when launched
not as a daemon but directly - this is extremely convenient for debugging), the
PeriodicWakeup event is not scheduled.
As a result, Log::flush_thread_main() does not wake up periodically, but only
on log buffer overflow. Coupled with a horribly wrong activation check in
Log::flush_thread_main():
{code}
if (now > last_time) {
if ((now % PERIODIC_TASKS_INTERVAL) == 0) {
// We run only when waken up at the moment which is exact
// multiple of PERIODIC_TASKS_INTERVAL!
{code}
this leads to that probability of any log output is low.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1606) Log buffers are not flushed periodically when TS is launched with NO_REMOTE_MANAGEMENT flag
[
https://issues.apache.org/jira/browse/TS-1606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yakov Markovitch updated TS-1606:
-
Affects Version/s: 3.3.0
3.2.0
> Log buffers are not flushed periodically when TS is launched with
> NO_REMOTE_MANAGEMENT flag
> ---
>
> Key: TS-1606
> URL: https://issues.apache.org/jira/browse/TS-1606
> Project: Traffic Server
> Issue Type: Bug
> Components: Logging
>Affects Versions: 3.3.0, 3.2.0
>Reporter: Yakov Markovitch
>
> When TS binary is launched with NO_REMOTE_MANAGEMENT flag (e.g., when
> launched not as a daemon but directly - this is extremely convenient for
> debugging), the PeriodicWakeup event is not scheduled.
> As a result, Log::flush_thread_main() does not wake up periodically, but only
> on log buffer overflow. Coupled with a horribly wrong activation check in
> Log::flush_thread_main():
> {code}
> if (now > last_time) {
> if ((now % PERIODIC_TASKS_INTERVAL) == 0) {
> // We run only when waken up at the moment which is exact
> // multiple of PERIODIC_TASKS_INTERVAL!
> {code}
> this leads to that probability of any log output is low.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-818) Assertion/abort when starting TS with SOCKS proxy enabled
[ https://issues.apache.org/jira/browse/TS-818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13043923#comment-13043923 ] Yakov Markovitch commented on TS-818: - Yes I think it would be great. Will allow to remove an actual showstopper for SOCKS proxy usage (aside from this bug SOCKS proxy works rather well, at least so far). > Assertion/abort when starting TS with SOCKS proxy enabled > - > > Key: TS-818 > URL: https://issues.apache.org/jira/browse/TS-818 > Project: Traffic Server > Issue Type: Bug > Components: Core >Affects Versions: 2.1.9, 2.1.8 > Environment: Linux x86-64 >Reporter: Yakov Markovitch >Assignee: Leif Hedstrom > Fix For: 3.1.0 > > Attachments: trafficserver.2.1.8.socks-reg-stat.patch > > > When attempting to start TS with > CONFIG proxy.config.socks.socks_needed INT 1 > CONFIG proxy.config.socks.socks_version INT 5 > TS aborts at startup with the following message: > FATAL: RecProcess.cc:738: failed assert `false` -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-818) Assertion/abort when starting TS with SOCKS proxy enabled
[ https://issues.apache.org/jira/browse/TS-818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yakov Markovitch updated TS-818: Attachment: trafficserver.2.1.8.socks-reg-stat.patch > Assertion/abort when starting TS with SOCKS proxy enabled > - > > Key: TS-818 > URL: https://issues.apache.org/jira/browse/TS-818 > Project: Traffic Server > Issue Type: Bug > Components: Core >Affects Versions: 2.1.9, 2.1.8 > Environment: Linux x86-64 >Reporter: Yakov Markovitch > Attachments: trafficserver.2.1.8.socks-reg-stat.patch > > > When attempting to start TS with > CONFIG proxy.config.socks.socks_needed INT 1 > CONFIG proxy.config.socks.socks_version INT 5 > TS aborts at startup with the following message: > FATAL: RecProcess.cc:738: failed assert `false` -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-818) Assertion/abort when starting TS with SOCKS proxy enabled
Assertion/abort when starting TS with SOCKS proxy enabled - Key: TS-818 URL: https://issues.apache.org/jira/browse/TS-818 Project: Traffic Server Issue Type: Bug Components: Core Affects Versions: 2.1.8, 2.1.9 Environment: Linux x86-64 Reporter: Yakov Markovitch When attempting to start TS with CONFIG proxy.config.socks.socks_needed INT 1 CONFIG proxy.config.socks.socks_version INT 5 TS aborts at startup with the following message: FATAL: RecProcess.cc:738: failed assert `false` -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-818) Assertion/abort when starting TS with SOCKS proxy enabled
[ https://issues.apache.org/jira/browse/TS-818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13043392#comment-13043392 ] Yakov Markovitch commented on TS-818: - The cause of the bug is in an attempt of duplicate registration in loadSocksConfiguration() (Socks.cc) of statistics counters proxy.process.socks.connections_successful, proxy.process.socks.connections_unsuccessful, and proxy.process.socks.connections_currently_open. To the moment of loadSocksConfiguration() call these counters are already registered by register_net_stats() (Net.cc), which is called from ink_net_init(). I've attached a small patch that fixes the bug. > Assertion/abort when starting TS with SOCKS proxy enabled > - > > Key: TS-818 > URL: https://issues.apache.org/jira/browse/TS-818 > Project: Traffic Server > Issue Type: Bug > Components: Core >Affects Versions: 2.1.9, 2.1.8 > Environment: Linux x86-64 >Reporter: Yakov Markovitch > > When attempting to start TS with > CONFIG proxy.config.socks.socks_needed INT 1 > CONFIG proxy.config.socks.socks_version INT 5 > TS aborts at startup with the following message: > FATAL: RecProcess.cc:738: failed assert `false` -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-770) proxy.config.http.doc_in_cache_skip_dns is not being read from records.config
[ https://issues.apache.org/jira/browse/TS-770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yakov Markovitch updated TS-770: Attachment: trafficserver.2.1.8.doc_in_cache_skip_dns.patch Patch that enables reading proxy.config.http.doc_in_cache_skip_dns value from recorda.config at TS start. > proxy.config.http.doc_in_cache_skip_dns is not being read from records.config > - > > Key: TS-770 > URL: https://issues.apache.org/jira/browse/TS-770 > Project: Traffic Server > Issue Type: Bug > Components: Configuration >Affects Versions: 2.1.8, 2.1.7, 2.1.6 >Reporter: Yakov Markovitch >Priority: Minor > Attachments: trafficserver.2.1.8.doc_in_cache_skip_dns.patch > > > The value of new configuration option proxy.config.http.doc_in_cache_skip_dns > is not read from records.config on TS start. > This is rather unfortunate, since its default value is 1 and our plugin needs > DNS on every transaction, even if the document is served from the cache. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-770) proxy.config.http.doc_in_cache_skip_dns is not being read from records.config
proxy.config.http.doc_in_cache_skip_dns is not being read from records.config - Key: TS-770 URL: https://issues.apache.org/jira/browse/TS-770 Project: Traffic Server Issue Type: Bug Components: Configuration Affects Versions: 2.1.6, 2.1.7, 2.1.8 Reporter: Yakov Markovitch Priority: Minor The value of new configuration option proxy.config.http.doc_in_cache_skip_dns is not read from records.config on TS start. This is rather unfortunate, since its default value is 1 and our plugin needs DNS on every transaction, even if the document is served from the cache. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-702) FATAL: MIME.cc:1250: failed assert `j < block_count`
[
https://issues.apache.org/jira/browse/TS-702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022780#comment-13022780
]
Yakov Markovitch commented on TS-702:
-
I've attached an updated patch with all issues addressed.
> FATAL: MIME.cc:1250: failed assert `j < block_count`
> -
>
> Key: TS-702
> URL: https://issues.apache.org/jira/browse/TS-702
> Project: Traffic Server
> Issue Type: Bug
> Components: MIME
>Affects Versions: 2.0.1
> Environment: Sun Blade X6240 (64G Ram), Running Linux Debian Lenny,
> Kernel 2.6.26-2-amd64
>Reporter: Ricky Chan
>Priority: Critical
> Fix For: 2.1.8
>
> Attachments: trafficserver.2.1.7.too.many.mimefields.patch
>
>
> I have 20 servers in a CDN farm which I brought live recently, I have noticed
> with in a day 5 servers had this error reported in traffic.out. Essentially
> aborting due to assertion failure. The server restarts (from traffic_cop).
> This platform has not had any load go through it yet, it's running around
> 5MB/s a second with around 25 connection per second. So doing much.
> I was going to migrate more traffic onto it, but holding off due to this
> assertion issue.
> Looking at the code, we have:
> for (j=0; j < block_count; j++) {
> ... with a condition which breaks out ..
> }
> ink_release_assert(j < block_count)
> So for this assert to be hit the entire list must be gone through without
> triggering the break clause, i.e. j == block_count
> I don't know this code well, is this a real bug or should the assert be there
> (or j <= block_count)?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-702) FATAL: MIME.cc:1250: failed assert `j < block_count`
[
https://issues.apache.org/jira/browse/TS-702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yakov Markovitch updated TS-702:
Attachment: trafficserver.2.1.7.too.many.mimefields.patch
Updated patch for mime_hdr_field_block_list_adjust
> FATAL: MIME.cc:1250: failed assert `j < block_count`
> -
>
> Key: TS-702
> URL: https://issues.apache.org/jira/browse/TS-702
> Project: Traffic Server
> Issue Type: Bug
> Components: MIME
>Affects Versions: 2.0.1
> Environment: Sun Blade X6240 (64G Ram), Running Linux Debian Lenny,
> Kernel 2.6.26-2-amd64
>Reporter: Ricky Chan
>Priority: Critical
> Fix For: 2.1.8
>
> Attachments: trafficserver.2.1.7.too.many.mimefields.patch
>
>
> I have 20 servers in a CDN farm which I brought live recently, I have noticed
> with in a day 5 servers had this error reported in traffic.out. Essentially
> aborting due to assertion failure. The server restarts (from traffic_cop).
> This platform has not had any load go through it yet, it's running around
> 5MB/s a second with around 25 connection per second. So doing much.
> I was going to migrate more traffic onto it, but holding off due to this
> assertion issue.
> Looking at the code, we have:
> for (j=0; j < block_count; j++) {
> ... with a condition which breaks out ..
> }
> ink_release_assert(j < block_count)
> So for this assert to be hit the entire list must be gone through without
> triggering the break clause, i.e. j == block_count
> I don't know this code well, is this a real bug or should the assert be there
> (or j <= block_count)?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-702) FATAL: MIME.cc:1250: failed assert `j < block_count`
[
https://issues.apache.org/jira/browse/TS-702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yakov Markovitch updated TS-702:
Attachment: (was: trafficserver.2.1.7.too.many.mimefields.patch)
> FATAL: MIME.cc:1250: failed assert `j < block_count`
> -
>
> Key: TS-702
> URL: https://issues.apache.org/jira/browse/TS-702
> Project: Traffic Server
> Issue Type: Bug
> Components: MIME
>Affects Versions: 2.0.1
> Environment: Sun Blade X6240 (64G Ram), Running Linux Debian Lenny,
> Kernel 2.6.26-2-amd64
>Reporter: Ricky Chan
>Priority: Critical
> Fix For: 2.1.8
>
>
> I have 20 servers in a CDN farm which I brought live recently, I have noticed
> with in a day 5 servers had this error reported in traffic.out. Essentially
> aborting due to assertion failure. The server restarts (from traffic_cop).
> This platform has not had any load go through it yet, it's running around
> 5MB/s a second with around 25 connection per second. So doing much.
> I was going to migrate more traffic onto it, but holding off due to this
> assertion issue.
> Looking at the code, we have:
> for (j=0; j < block_count; j++) {
> ... with a condition which breaks out ..
> }
> ink_release_assert(j < block_count)
> So for this assert to be hit the entire list must be gone through without
> triggering the break clause, i.e. j == block_count
> I don't know this code well, is this a real bug or should the assert be there
> (or j <= block_count)?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-702) FATAL: MIME.cc:1250: failed assert `j < block_count`
[
https://issues.apache.org/jira/browse/TS-702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021570#comment-13021570
]
Yakov Markovitch commented on TS-702:
-
This bug is in the algorithm of adjusting pointers inside MIME field blocks
after copying MIME headers. mime_hdr_copy_onto, which is directly called from
TSMimeHdrCopy and indirectly from TSMimeHdrClone, copies MIME headers as raw
memory blocks and then calls mime_hdr_field_block_list_adjust to adjust fields'
internal pointers to duplicates (MIMEField::m_next_dup).
The algorithm of mime_hdr_field_block_list_adjust is both complicated and
incorrect, since it implicitly assumes relative offsets between original and
copied blocks do not change. Worse is, they most often actually do not change,
accidentally: the source blocks allocated continuously, as well as target
blocks. The bug is very insidious and hard to reproduce, to manifest itself it
needs _all_ the following:
1. There must be more than one block allocated for a header, i.e. the header
must contain more than MIME_FIELD_BLOCK_SLOTS (==16) fields.
2. There must be duplicated fields in the header, and at least some of those
fields must be allocated not in the first block.
3. Relative offsets between target heap blocks must not match offsets between
source blocks.
I've attached a patch that fixes the bug. The patch was tested in production
environment.
> FATAL: MIME.cc:1250: failed assert `j < block_count`
> -
>
> Key: TS-702
> URL: https://issues.apache.org/jira/browse/TS-702
> Project: Traffic Server
> Issue Type: Bug
> Components: MIME
>Affects Versions: 2.0.1
> Environment: Sun Blade X6240 (64G Ram), Running Linux Debian Lenny,
> Kernel 2.6.26-2-amd64
>Reporter: Ricky Chan
>Priority: Critical
> Attachments: trafficserver.2.1.7.too.many.mimefields.patch
>
>
> I have 20 servers in a CDN farm which I brought live recently, I have noticed
> with in a day 5 servers had this error reported in traffic.out. Essentially
> aborting due to assertion failure. The server restarts (from traffic_cop).
> This platform has not had any load go through it yet, it's running around
> 5MB/s a second with around 25 connection per second. So doing much.
> I was going to migrate more traffic onto it, but holding off due to this
> assertion issue.
> Looking at the code, we have:
> for (j=0; j < block_count; j++) {
> ... with a condition which breaks out ..
> }
> ink_release_assert(j < block_count)
> So for this assert to be hit the entire list must be gone through without
> triggering the break clause, i.e. j == block_count
> I don't know this code well, is this a real bug or should the assert be there
> (or j <= block_count)?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-702) FATAL: MIME.cc:1250: failed assert `j < block_count`
[
https://issues.apache.org/jira/browse/TS-702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yakov Markovitch updated TS-702:
Attachment: trafficserver.2.1.7.too.many.mimefields.patch
Fix for the bug in MIME header blocks relocation after copy MIME headers copy.
> FATAL: MIME.cc:1250: failed assert `j < block_count`
> -
>
> Key: TS-702
> URL: https://issues.apache.org/jira/browse/TS-702
> Project: Traffic Server
> Issue Type: Bug
> Components: MIME
>Affects Versions: 2.0.1
> Environment: Sun Blade X6240 (64G Ram), Running Linux Debian Lenny,
> Kernel 2.6.26-2-amd64
>Reporter: Ricky Chan
>Priority: Critical
> Attachments: trafficserver.2.1.7.too.many.mimefields.patch
>
>
> I have 20 servers in a CDN farm which I brought live recently, I have noticed
> with in a day 5 servers had this error reported in traffic.out. Essentially
> aborting due to assertion failure. The server restarts (from traffic_cop).
> This platform has not had any load go through it yet, it's running around
> 5MB/s a second with around 25 connection per second. So doing much.
> I was going to migrate more traffic onto it, but holding off due to this
> assertion issue.
> Looking at the code, we have:
> for (j=0; j < block_count; j++) {
> ... with a condition which breaks out ..
> }
> ink_release_assert(j < block_count)
> So for this assert to be hit the entire list must be gone through without
> triggering the break clause, i.e. j == block_count
> I don't know this code well, is this a real bug or should the assert be there
> (or j <= block_count)?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (TS-420) TS fails to use user ID with user name longer than 8 characters
[ https://issues.apache.org/jira/browse/TS-420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yakov Markovitch updated TS-420: Attachment: ts.login.2.0.0.patch ts.login.trunk.patch Attached patches against 2.0.0 and trunk that fix this bug. > TS fails to use user ID with user name longer than 8 characters > --- > > Key: TS-420 > URL: https://issues.apache.org/jira/browse/TS-420 > Project: Traffic Server > Issue Type: Bug > Components: Core >Affects Versions: 2.1.1, 2.1.0, 2.0.1, 2.0.0 > Environment: OpenSUSE Linux 11.3 > Kernel 2.6.34-12 64-bit >Reporter: Yakov Markovitch >Priority: Critical > Attachments: ts.login.2.0.0.patch, ts.login.trunk.patch > > > Attempt to configure proxy.config.admin.user_id with username of length > longer than 8 characters causes TS to fail at startup. TS fails attempting to > change uid using the first 8 characters of the username. > E.g. (from records.config): > CONFIG proxy.config.admin.user_id STRING bandersnatch > TS fails with message: > FATAL: Can't find entry in password file for user: bandersn -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TS-420) TS fails to use user ID with user name longer than 8 characters
TS fails to use user ID with user name longer than 8 characters --- Key: TS-420 URL: https://issues.apache.org/jira/browse/TS-420 Project: Traffic Server Issue Type: Bug Components: Core Affects Versions: 2.0.0, 2.1.0, 2.1.1, 2.0.1 Environment: OpenSUSE Linux 11.3 Kernel 2.6.34-12 64-bit Reporter: Yakov Markovitch Priority: Critical Attempt to configure proxy.config.admin.user_id with username of length longer than 8 characters causes TS to fail at startup. TS fails attempting to change uid using the first 8 characters of the username. E.g. (from records.config): CONFIG proxy.config.admin.user_id STRING bandersnatch TS fails with message: FATAL: Can't find entry in password file for user: bandersn -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (TS-419) Segmentation fault in INKError when error output is made both in error log and as debug messages
[
https://issues.apache.org/jira/browse/TS-419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12900705#action_12900705
]
Yakov Markovitch edited comment on TS-419 at 8/20/10 10:29 AM:
---
Here the patch that fixes the bug. Works both against 2.0.0 and the trunk.
was (Author: ymarkovitch):
Here the patch that fixes the bug. Works both again 2.0.0 and the trunk.
> Segmentation fault in INKError when error output is made both in error log
> and as debug messages
> --
>
> Key: TS-419
> URL: https://issues.apache.org/jira/browse/TS-419
> Project: Traffic Server
> Issue Type: Bug
> Components: InkAPI
>Affects Versions: 2.1.1, 2.1.0, 2.0.1, 2.0.0
>Reporter: Yakov Markovitch
> Attachments: INKError.patch
>
>
> When TS is configures so that to print INKError messages both to the error
> log and as debug messages (e.g. by starting TS with -B 'deft'), calling
> INKError with variable arguments (like INKError("The answer to the %s is %d",
> "Ultimate Question of Life, the Universe, and Everything", 42)) causes
> segfault.
> The cause of this bug is that INKError uses once initialised va_args pointer
> two times.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TS-419) Segmentation fault in INKError when error output is made both in error log and as debug messages
[
https://issues.apache.org/jira/browse/TS-419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yakov Markovitch updated TS-419:
Attachment: INKError.patch
Here the patch that fixes the bug. Works both again 2.0.0 and the trunk.
> Segmentation fault in INKError when error output is made both in error log
> and as debug messages
> --
>
> Key: TS-419
> URL: https://issues.apache.org/jira/browse/TS-419
> Project: Traffic Server
> Issue Type: Bug
> Components: InkAPI
>Affects Versions: 2.1.1, 2.1.0, 2.0.1, 2.0.0
>Reporter: Yakov Markovitch
> Attachments: INKError.patch
>
>
> When TS is configures so that to print INKError messages both to the error
> log and as debug messages (e.g. by starting TS with -B 'deft'), calling
> INKError with variable arguments (like INKError("The answer to the %s is %d",
> "Ultimate Question of Life, the Universe, and Everything", 42)) causes
> segfault.
> The cause of this bug is that INKError uses once initialised va_args pointer
> two times.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (TS-419) Segmentation fault in INKError when error output is made both in error log and as debug messages
Segmentation fault in INKError when error output is made both in error log and
as debug messages
--
Key: TS-419
URL: https://issues.apache.org/jira/browse/TS-419
Project: Traffic Server
Issue Type: Bug
Components: InkAPI
Affects Versions: 2.0.0, 2.1.0, 2.1.1, 2.0.1
Reporter: Yakov Markovitch
When TS is configures so that to print INKError messages both to the error log
and as debug messages (e.g. by starting TS with -B 'deft'), calling INKError
with variable arguments (like INKError("The answer to the %s is %d", "Ultimate
Question of Life, the Universe, and Everything", 42)) causes segfault.
The cause of this bug is that INKError uses once initialised va_args pointer
two times.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
