[jira] [Updated] (CASSANDRA-16027) bin/cassandra may fail to execute in certain environments due to unhandled output pipe
[
https://issues.apache.org/jira/browse/CASSANDRA-16027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paulo Motta updated CASSANDRA-16027:
Bug Category: Parent values: Packaging(13660)Level 1 values: All(13663)
Complexity: Low Hanging Fruit
Component/s: Packaging
Discovered By: User Report
Severity: Low
Status: Open (was: Triage Needed)
> bin/cassandra may fail to execute in certain environments due to unhandled
> output pipe
> --
>
> Key: CASSANDRA-16027
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16027
> Project: Cassandra
> Issue Type: Bug
> Components: Packaging
>Reporter: Christopher Bradford
>Priority: Normal
>
> While developing Docker images for C* 3.11.6 I noticed bin/cassandra failed
> to start when executed with nohup in a container based Red Hat Universal Base
> Image on Kubernetes. Curiously this issue could not be reproduced when simply
> running the container on Docker. Instead it had to be scheduled within a k8s
> pod.
>
> Running an strace indicates the following:
> {code:java}
> [pid 3666026] write(2, "OpenJDK 64-Bit Server VM warning: ", 34) = -1 EPIPE
> (Broken pipe) {code}
>
> The issue occurs before the system.log file is created. After further digging
> in to the command being run it was determined the bin/cassandra file was not
> redirecting all output pipes. In this particular environment this leads to
> the process going defunct and no Cassandra running.
>
> The 4 lines starting with
> {code:java}
> exec $NUMACTL {code}
> are not handling one of the outputs (stderr or stdout). As a workaround
> suffixing each line with
> {code:java}
> > /var/log/cassandra/stdout.log 2> /var/log/cassandra/stderr.log
> {code}
> {{resolves the issue and Cassandra starts without any issues.}}
>
> {{Rather than bake this into our containers the fix should make its way
> upstream.}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16027) bin/cassandra may fail to execute in certain environments due to unhandled output pipe
[
https://issues.apache.org/jira/browse/CASSANDRA-16027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paulo Motta updated CASSANDRA-16027:
Labels: lhf (was: )
> bin/cassandra may fail to execute in certain environments due to unhandled
> output pipe
> --
>
> Key: CASSANDRA-16027
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16027
> Project: Cassandra
> Issue Type: Bug
> Components: Packaging
>Reporter: Christopher Bradford
>Priority: Normal
> Labels: lhf
>
> While developing Docker images for C* 3.11.6 I noticed bin/cassandra failed
> to start when executed with nohup in a container based Red Hat Universal Base
> Image on Kubernetes. Curiously this issue could not be reproduced when simply
> running the container on Docker. Instead it had to be scheduled within a k8s
> pod.
>
> Running an strace indicates the following:
> {code:java}
> [pid 3666026] write(2, "OpenJDK 64-Bit Server VM warning: ", 34) = -1 EPIPE
> (Broken pipe) {code}
>
> The issue occurs before the system.log file is created. After further digging
> in to the command being run it was determined the bin/cassandra file was not
> redirecting all output pipes. In this particular environment this leads to
> the process going defunct and no Cassandra running.
>
> The 4 lines starting with
> {code:java}
> exec $NUMACTL {code}
> are not handling one of the outputs (stderr or stdout). As a workaround
> suffixing each line with
> {code:java}
> > /var/log/cassandra/stdout.log 2> /var/log/cassandra/stderr.log
> {code}
> {{resolves the issue and Cassandra starts without any issues.}}
>
> {{Rather than bake this into our containers the fix should make its way
> upstream.}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16027) bin/cassandra may fail to execute in certain environments due to unhandled output pipe
[
https://issues.apache.org/jira/browse/CASSANDRA-16027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Bradford updated CASSANDRA-16027:
-
Description:
While developing Docker images for C* 3.11.6 I noticed bin/cassandra failed to
start when executed with nohup in a container based Red Hat Universal Base
Image on Kubernetes. Curiously this issue could not be reproduced when simply
running the container on Docker. Instead it had to be scheduled within a k8s
pod.
Running an strace indicates the following:
{code:java}
[pid 3666026] write(2, "OpenJDK 64-Bit Server VM warning: ", 34) = -1 EPIPE
(Broken pipe) {code}
The issue occurs before the system.log file is created. After further digging
in to the command being run it was determined the bin/cassandra file was not
redirecting all output pipes. In this particular environment this leads to the
process going defunct and no Cassandra running.
The 4 lines starting with
{code:java}
exec $NUMACTL {code}
are not handling one of the outputs (stderr or stdout). As a workaround
suffixing each line with
{code:java}
> /var/log/cassandra/stdout.log 2> /var/log/cassandra/stderr.log
{code}
{{resolves the issue and Cassandra starts without any issues.}}
{{Rather than bake this into our containers the fix should make its way
upstream.}}
was:
While developing Docker images for C* 3.11.6 I noticed bin/cassandra failed to
start when executed with nohup in a container based Red Hat Universal Base
Image on Kubernetes. Curiously this issue could not be reproduced when simply
running the container on Docker. Instead it had to be scheduled within a k8s
pod.
Running an strace indicates the following:
{code:java}
[pid 3666026] write(2, "OpenJDK 64-Bit Server VM warning: ", 34) = -1 EPIPE
(Broken pipe) {code}
The issue occurs before the system.log file is created. After further digging
in to the command being run it was determined the bin/cassandra file was not
redirecting all output pipes. In this particular environment this leads to the
process going defunct and no Cassandra running.
{{The 4 lines starting with }}
{code:java}
exec $NUMACTL {code}
{{are not handling one of the outputs (stderr or stdout). As a workaround
suffixing each line with }}
{code:java}
> /var/log/cassandra/stdout.log 2> /var/log/cassandra/stderr.log
{code}
{{resolves the issue and Cassandra starts without any issues.}}
{{Rather than bake this into our containers the fix should make its way
upstream.}}
> bin/cassandra may fail to execute in certain environments due to unhandled
> output pipe
> --
>
> Key: CASSANDRA-16027
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16027
> Project: Cassandra
> Issue Type: Bug
>Reporter: Christopher Bradford
>Priority: Normal
>
> While developing Docker images for C* 3.11.6 I noticed bin/cassandra failed
> to start when executed with nohup in a container based Red Hat Universal Base
> Image on Kubernetes. Curiously this issue could not be reproduced when simply
> running the container on Docker. Instead it had to be scheduled within a k8s
> pod.
>
> Running an strace indicates the following:
> {code:java}
> [pid 3666026] write(2, "OpenJDK 64-Bit Server VM warning: ", 34) = -1 EPIPE
> (Broken pipe) {code}
>
> The issue occurs before the system.log file is created. After further digging
> in to the command being run it was determined the bin/cassandra file was not
> redirecting all output pipes. In this particular environment this leads to
> the process going defunct and no Cassandra running.
>
> The 4 lines starting with
> {code:java}
> exec $NUMACTL {code}
> are not handling one of the outputs (stderr or stdout). As a workaround
> suffixing each line with
> {code:java}
> > /var/log/cassandra/stdout.log 2> /var/log/cassandra/stderr.log
> {code}
> {{resolves the issue and Cassandra starts without any issues.}}
>
> {{Rather than bake this into our containers the fix should make its way
> upstream.}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
