Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Hostname Resolution Error for TcpipServerInterface.py #1911

Closed
roobixx opened this issue Feb 21, 2025 · 4 comments · Fixed by #1915
Closed

Hostname Resolution Error for TcpipServerInterface.py #1911

roobixx opened this issue Feb 21, 2025 · 4 comments · Fixed by #1915
Assignees

Comments

@roobixx
Copy link

roobixx commented Feb 21, 2025

Describe the bug
I have the following code to replicate the step Ryan took in the RASCube/COSMOS YouTube Video with some modifications from his code.

### gs_bridge.py

import serial
import sys
import time
import struct
from openc3.interfaces.tcpip_server_interface import TcpipServerInterface
from openc3.packets.packet import Packet

port = 2945
if len(sys.argv) > 2:
    port = sys.argv[2]

a = TcpipServerInterface(port, port, 10, None, "BURST")
a.connect()

id = 1 # This is for testing with COSMOS. Every pkt needs and ID and PROVESKit does not have IDs.


with serial.Serial(sys.argv[1], 115200) as ser:
    while True:
        data = ser.read_until(b"\n")
        pkt_len = len(data)
        pkt = struct.pack(f"bb{pkt_len}s", id, pkt_len, data)
        packet = Packet()
        packet.buffer = pkt
        a.write(packet)

I have installed the openc3 library from PIP and when I run the code I get the following error and COSMOS does not ever connect to the server:

Exception in thread Thread-1 (_listen_thread_body):
Traceback (most recent call last):
  File "/usr/lib/python3.11/threading.py", line 1038, in _bootstrap_inner
    self.run()
  File "/usr/lib/python3.11/threading.py", line 975, in run
    self._target(*self._args, **self._kwargs)
  File "/home/rbx/.local/lib/python3.11/site-packages/openc3/interfaces/tcpip_server_interface.py", line 377, in _listen_thread_body
    hostname, _, _ = socket.gethostbyaddr(host_ip)
                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
socket.herror: [Errno 1] Unknown host

I was able to get around this error by setting an entry in /etc/hosts for the Operator container's IP address

Image

Doing this effectively fixes the primary issue but when running the bridge code again, COSMOS will connect but it still results in a name resolution failures, but it does work as expected.

{"time": 1740170507992497920, "@timestamp": "2025-02-21T20:41:47.992498Z", "level": "INFO", "container_name": "debian", "message": "TcpipServerInterface: Tcpip server accepted connection from cosmos-openc3-operator-1(172.18.0.6):48810", "type": "log"}
Exception in thread Thread-5 (store_thread_body):
Traceback (most recent call last):
  File "/home/rbx/.local/lib/python3.11/site-packages/redis/connection.py", line 707, in connect
    sock = self.retry.call_with_retry(
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/rbx/.local/lib/python3.11/site-packages/redis/retry.py", line 46, in call_with_retry
    return do()
           ^^^^
  File "/home/rbx/.local/lib/python3.11/site-packages/redis/connection.py", line 708, in <lambda>
    lambda: self._connect(), lambda error: self.disconnect(error)
            ^^^^^^^^^^^^^^^
  File "/home/rbx/.local/lib/python3.11/site-packages/redis/connection.py", line 974, in _connect
    for res in socket.getaddrinfo(
               ^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/socket.py", line 962, in getaddrinfo
    for res in _socket.getaddrinfo(host, port, family, type, proto, flags):
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
socket.gaierror: [Errno -2] Name or service not known

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3.11/threading.py", line 1038, in _bootstrap_inner
    self.run()
  File "/usr/lib/python3.11/threading.py", line 975, in run
    self._target(*self._args, **self._kwargs)
  File "/home/rbx/.local/lib/python3.11/site-packages/openc3/utilities/store_queued.py", line 92, in store_thread_body
    self.process_queue()
  File "/home/rbx/.local/lib/python3.11/site-packages/openc3/utilities/store_queued.py", line 83, in process_queue
    with self.store.redis_pool.pipelined():
  File "/usr/lib/python3.11/contextlib.py", line 144, in __exit__
    next(self.gen)
  File "/home/rbx/.local/lib/python3.11/site-packages/openc3/utilities/store_implementation.py", line 43, in pipelined
    pipeline.execute()
  File "/home/rbx/.local/lib/python3.11/site-packages/redis/client.py", line 2114, in execute
    conn = self.connection_pool.get_connection("MULTI", self.shard_hint)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/rbx/.local/lib/python3.11/site-packages/redis/connection.py", line 1461, in get_connection
    connection.connect()
  File "/home/rbx/.local/lib/python3.11/site-packages/redis/connection.py", line 713, in connect
    raise ConnectionError(self._error_message(e))
redis.exceptions.ConnectionError: Error -2 connecting to openc3-redis-ephemeral:6380. Name or service not known.

I am pretty sure this is just and issue with Docker specifically but seeing as @ryanmelt did not show this same behavior, I am not sure if it is.

I have tried this in both Debian and Ubuntu VMs with the exact same results and it certainly is not a big issue. I am just trying to understand the underlying issue.

Environment (please complete the following information):

  • OS: Ubuntu 24.04.1 / Debian 12
  • OpenC3 COSMOS Version 6.1.0
@ryanmelt
Copy link
Member

This is definitely an issue where we should be catching that exception. I'm not sure why I didn't have this issue though... let me dig into that.

@ryanmelt
Copy link
Member

Your last errors can be removed by setting environment OPENC3_NO_STORE=1

@ryanmelt
Copy link
Member

For me the connection from docker on the same computer showed up as "localhost" which successfully resolved to 127.0.0.1 so no crashing exception.

I'll add code to catch that exception right now and we'll get it into the 6.2.0 release.

@roobixx
Copy link
Author

roobixx commented Feb 22, 2025

I wonder it there is something different with Docker Desktop version on Docker engine that could be causing it the initial issue. For me the connection is always coming from the operator container's network address.

Regardless thanks for the quick resolution.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants