[jira] [Commented] (CASSANDRA-8022) cqlsh hangs indefinitely within a Docker container connecting to itself with hostname
[
https://issues.apache.org/jira/browse/CASSANDRA-8022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14201420#comment-14201420
]
Mikhail Stepura commented on CASSANDRA-8022:
I doubt that is network related. I suspect it's a way cqlsh is launched. It
prints no prompt, so I guess cqlsh 'thinks' it is launched not from a terminal
( i.e. {{sys.stdin.isatty() == false}}).
> cqlsh hangs indefinitely within a Docker container connecting to itself with
> hostname
> -
>
> Key: CASSANDRA-8022
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8022
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
> Environment: Ubuntu 14.04, running Docker, run inside a Ubuntu 14.04
> container.
>Reporter: Matthew O'Riordan
> Labels: cqlsh
>
> I am unable to use the `cqlsh` tool within a Docker container running
> Cassandra. Previously I would use the Java & Thrift based `cqlsh` tool as
> follows:
> ```
> cqlsh --username cassandra --password whatever $(hostname)
> ```
> When I run the `cqlsh` command after attaching to a running container (I use
> LXC containerisation that allows attaching to a running container and running
> a console), it simply hangs and never reports an error. With the `--debug`
> flag on, I get the following with:
> **cqlsh 4.1.1**
> ```
> $ cqlsh --debug --username cassandra --password obfuscated $(hostname)
> Using CQL driver: '/usr/share/cassandra/lib/cql-internal-only-1.4.1.zip/cql-1.4.1/cql/__init__.py'>
> Using thrift lib: '/usr/share/cassandra/lib/thrift-python-internal-only-0.9.1.zip/thrift/__init__.py'>
> ```
> It then hangs in this state indefinitely, I have no errors from `cqlsh` and
> no errors in the Cassandra log.
> **cqlsh 5.0.1**
> ```
> $ cqlsh --debug --username cassandra --passwor obfuscated $(hostname)
> Using CQL driver: '/usr/share/cassandra/lib/cassandra-driver-internal-only-2.1.0.post.zip/cassandra-driver-2.1.0.post/cassandra/__init__.py'>
> ```
> It then also hangs in this state indefinitely, I have no errors from `cqlsh`
> and no errors in the Cassandra log.
> What's interesting, and quite confusing is that:
> * I can telnet within the container as follows `telnet $(hostname) 9042` and
> I get a socket. When trying to issue some commands, I see Protocol errors in
> the Cassandra log thus verifying that the port is indeed open on the host
> that resolves from $(hostname)
> * If I `cqlsh` from another container or another host to the Cassandra
> container it works just fine.
> * I have tried disabling authentication altogether and using the
> AllowAllAuthenticator, and I experience the same problem.
> * `nodetool` works fine
> In the mean time, I am forced to `cqlsh` from another container as a
> workaround. Happy to try and do anything require to diagnose the cause of
> this problem.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8022) cqlsh hangs indefinitely within a Docker container connecting to itself with hostname
[ https://issues.apache.org/jira/browse/CASSANDRA-8022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14200513#comment-14200513 ] Michael Shuler commented on CASSANDRA-8022: --- Without using hostnames, do container IP addresses work with cqlsh? If not, then it seems to be a host<->guest network routing problem. If IPs work, then it's a DNS resolution problem. I would guess that $hostname on the host and in container resolve different IP addresses? > cqlsh hangs indefinitely within a Docker container connecting to itself with > hostname > - > > Key: CASSANDRA-8022 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8022 > Project: Cassandra > Issue Type: Bug > Components: Tools > Environment: Ubuntu 14.04, running Docker, run inside a Ubuntu 14.04 > container. >Reporter: Matthew O'Riordan > Labels: cqlsh > > I am unable to use the `cqlsh` tool within a Docker container running > Cassandra. Previously I would use the Java & Thrift based `cqlsh` tool as > follows: > ``` > cqlsh --username cassandra --password whatever $(hostname) > ``` > When I run the `cqlsh` command after attaching to a running container (I use > LXC containerisation that allows attaching to a running container and running > a console), it simply hangs and never reports an error. With the `--debug` > flag on, I get the following with: > **cqlsh 4.1.1** > ``` > $ cqlsh --debug --username cassandra --password obfuscated $(hostname) > Using CQL driver: '/usr/share/cassandra/lib/cql-internal-only-1.4.1.zip/cql-1.4.1/cql/__init__.py'> > Using thrift lib: '/usr/share/cassandra/lib/thrift-python-internal-only-0.9.1.zip/thrift/__init__.py'> > ``` > It then hangs in this state indefinitely, I have no errors from `cqlsh` and > no errors in the Cassandra log. > **cqlsh 5.0.1** > ``` > $ cqlsh --debug --username cassandra --passwor obfuscated $(hostname) > Using CQL driver: '/usr/share/cassandra/lib/cassandra-driver-internal-only-2.1.0.post.zip/cassandra-driver-2.1.0.post/cassandra/__init__.py'> > ``` > It then also hangs in this state indefinitely, I have no errors from `cqlsh` > and no errors in the Cassandra log. > What's interesting, and quite confusing is that: > * I can telnet within the container as follows `telnet $(hostname) 9042` and > I get a socket. When trying to issue some commands, I see Protocol errors in > the Cassandra log thus verifying that the port is indeed open on the host > that resolves from $(hostname) > * If I `cqlsh` from another container or another host to the Cassandra > container it works just fine. > * I have tried disabling authentication altogether and using the > AllowAllAuthenticator, and I experience the same problem. > * `nodetool` works fine > In the mean time, I am forced to `cqlsh` from another container as a > workaround. Happy to try and do anything require to diagnose the cause of > this problem. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8022) cqlsh hangs indefinitely within a Docker container connecting to itself with hostname
[ https://issues.apache.org/jira/browse/CASSANDRA-8022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14152622#comment-14152622 ] Matthew O'Riordan commented on CASSANDRA-8022: -- Yes, I can enter "commands" in, but they are simply echoed back to me, nothing happens. I've attached another console to the container that is running cqlsh, and run the `lsof` command: ``` lsof -a -p 614 -d0,1,2 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME python 614 root0u CHR 136,11 0t0 14 /dev/pts/11 python 614 root1w FIFO0,8 0t0 661702 pipe python 614 root2w FIFO0,8 0t0 661702 pipe ``` PS. Sorry, I am not familiar with JIRA markup, and the link below does not work for help on the formatting, how do you mark text as code? > cqlsh hangs indefinitely within a Docker container connecting to itself with > hostname > - > > Key: CASSANDRA-8022 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8022 > Project: Cassandra > Issue Type: Bug > Components: Tools > Environment: Ubuntu 14.04, running Docker, run inside a Ubuntu 14.04 > container. >Reporter: Matthew O'Riordan > Fix For: 2.1.0 > > > I am unable to use the `cqlsh` tool within a Docker container running > Cassandra. Previously I would use the Java & Thrift based `cqlsh` tool as > follows: > ``` > cqlsh --username cassandra --password whatever $(hostname) > ``` > When I run the `cqlsh` command after attaching to a running container (I use > LXC containerisation that allows attaching to a running container and running > a console), it simply hangs and never reports an error. With the `--debug` > flag on, I get the following with: > **cqlsh 4.1.1** > ``` > $ cqlsh --debug --username cassandra --password obfuscated $(hostname) > Using CQL driver: '/usr/share/cassandra/lib/cql-internal-only-1.4.1.zip/cql-1.4.1/cql/__init__.py'> > Using thrift lib: '/usr/share/cassandra/lib/thrift-python-internal-only-0.9.1.zip/thrift/__init__.py'> > ``` > It then hangs in this state indefinitely, I have no errors from `cqlsh` and > no errors in the Cassandra log. > **cqlsh 5.0.1** > ``` > $ cqlsh --debug --username cassandra --passwor obfuscated $(hostname) > Using CQL driver: '/usr/share/cassandra/lib/cassandra-driver-internal-only-2.1.0.post.zip/cassandra-driver-2.1.0.post/cassandra/__init__.py'> > ``` > It then also hangs in this state indefinitely, I have no errors from `cqlsh` > and no errors in the Cassandra log. > What's interesting, and quite confusing is that: > * I can telnet within the container as follows `telnet $(hostname) 9042` and > I get a socket. When trying to issue some commands, I see Protocol errors in > the Cassandra log thus verifying that the port is indeed open on the host > that resolves from $(hostname) > * If I `cqlsh` from another container or another host to the Cassandra > container it works just fine. > * I have tried disabling authentication altogether and using the > AllowAllAuthenticator, and I experience the same problem. > * `nodetool` works fine > In the mean time, I am forced to `cqlsh` from another container as a > workaround. Happy to try and do anything require to diagnose the cause of > this problem. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8022) cqlsh hangs indefinitely within a Docker container connecting to itself with hostname
[
https://issues.apache.org/jira/browse/CASSANDRA-8022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14152514#comment-14152514
]
Mikhail Stepura commented on CASSANDRA-8022:
Can you enter commands into that "hung" cqlsh?
Can you also check the output for {{ lsof -a -p -d0,1,2}} ?
> cqlsh hangs indefinitely within a Docker container connecting to itself with
> hostname
> -
>
> Key: CASSANDRA-8022
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8022
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
> Environment: Ubuntu 14.04, running Docker, run inside a Ubuntu 14.04
> container.
>Reporter: Matthew O'Riordan
> Fix For: 2.1.0
>
>
> I am unable to use the `cqlsh` tool within a Docker container running
> Cassandra. Previously I would use the Java & Thrift based `cqlsh` tool as
> follows:
> ```
> cqlsh --username cassandra --password whatever $(hostname)
> ```
> When I run the `cqlsh` command after attaching to a running container (I use
> LXC containerisation that allows attaching to a running container and running
> a console), it simply hangs and never reports an error. With the `--debug`
> flag on, I get the following with:
> **cqlsh 4.1.1**
> ```
> $ cqlsh --debug --username cassandra --password obfuscated $(hostname)
> Using CQL driver: '/usr/share/cassandra/lib/cql-internal-only-1.4.1.zip/cql-1.4.1/cql/__init__.py'>
> Using thrift lib: '/usr/share/cassandra/lib/thrift-python-internal-only-0.9.1.zip/thrift/__init__.py'>
> ```
> It then hangs in this state indefinitely, I have no errors from `cqlsh` and
> no errors in the Cassandra log.
> **cqlsh 5.0.1**
> ```
> $ cqlsh --debug --username cassandra --passwor obfuscated $(hostname)
> Using CQL driver: '/usr/share/cassandra/lib/cassandra-driver-internal-only-2.1.0.post.zip/cassandra-driver-2.1.0.post/cassandra/__init__.py'>
> ```
> It then also hangs in this state indefinitely, I have no errors from `cqlsh`
> and no errors in the Cassandra log.
> What's interesting, and quite confusing is that:
> * I can telnet within the container as follows `telnet $(hostname) 9042` and
> I get a socket. When trying to issue some commands, I see Protocol errors in
> the Cassandra log thus verifying that the port is indeed open on the host
> that resolves from $(hostname)
> * If I `cqlsh` from another container or another host to the Cassandra
> container it works just fine.
> * I have tried disabling authentication altogether and using the
> AllowAllAuthenticator, and I experience the same problem.
> * `nodetool` works fine
> In the mean time, I am forced to `cqlsh` from another container as a
> workaround. Happy to try and do anything require to diagnose the cause of
> this problem.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
