docker run zenoh router fails without tty flag

[ggari-robotnik]

Description of the Issue

I just created a container where rmw_zenoh deb packages are created and installed on the container.

Here is my compose file where the router works fine:

---
name: "zenoh_rmw"
services:
  router:
    image: >-
      ${REGISTRY_BASE}${PROJECT}/${IMAGE_NAME}:${DOCKER_ROS_DISTRO}-${VERSION}
    tty: true
    command: "ros2 run rmw_zenoh_cpp rmw_zenohd"
    stop_signal: SIGTERM

If run the container without tty:true

---
name: "zenoh_rmw"
services:
  router:
    image: >-
      ${REGISTRY_BASE}${PROJECT}/${IMAGE_NAME}:${DOCKER_ROS_DISTRO}-${VERSION}
    #tty: true
    command: "ros2 run rmw_zenoh_cpp rmw_zenohd"
    stop_signal: SIGTERM

docker compose up

The output:

router-1  | 2024-06-21T12:56:01.011224Z DEBUG ThreadId(02) zenoh::session: Config: Config { id: fca00e661bceb62e60cc864b7882c12e, metadata: Null, mode: Some(Router), connect: ConnectConfig { timeout_ms: None, endpoints: [], exit_on_failure: None, retry: None }, listen: ListenConfig { timeout_ms: None, endpoints: [tcp/[::]:7447], exit_on_failure: None, retry: None }, scouting: ScoutingConf { timeout: Some(3000), delay: Some(1), multicast: ScoutingMulticastConf { enabled: Some(false), address: Some(224.0.0.224:7446), interface: Some("auto"), ttl: None, autoconnect: Some(Dependent(ModeValues { router: Some(WhatAmIMatcher(128)), peer: Some(WhatAmIMatcher(131)), client: None })), listen: Some(Unique(true)) }, gossip: GossipConf { enabled: Some(true), multihop: Some(false), autoconnect: Some(Dependent(ModeValues { router: Some(WhatAmIMatcher(128)), peer: Some(WhatAmIMatcher(131)), client: None })) } }, timestamping: TimestampingConf { enabled: Some(Dependent(ModeValues { router: Some(true), peer: Some(true), client: Some(false) })), drop_future_timestamp: Some(false) }, queries_default_timeout: Some(10000), routing: RoutingConf { router: RouterRoutingConf { peers_failover_brokering: Some(true) }, peer: PeerRoutingConf { mode: Some("peer_to_peer") } }, aggregation: AggregationConf { subscribers: [], publishers: [] }, transport: TransportConf { unicast: TransportUnicastConf { accept_timeout: 10000, accept_pending: 100, max_sessions: 1000, max_links: 1, lowlatency: false, qos: QoSUnicastConf { enabled: true }, compression: CompressionUnicastConf { enabled: false } }, multicast: TransportMulticastConf { join_interval: Some(2500), max_sessions: Some(1000), qos: QoSMulticastConf { enabled: false }, compression: CompressionMulticastConf { enabled: false } }, link: TransportLinkConf { protocols: None, tx: LinkTxConf { sequence_number_resolution: U32, lease: 10000, keep_alive: 4, batch_size: 65535, queue: QueueConf { size: QueueSizeConf { control: 1, real_time: 1, interactive_high: 1, interactive_low: 1, data_high: 2, data: 4, data_low: 4, background: 4 }, congestion_control: CongestionControlConf { wait_before_drop: 1000 }, backoff: 100 }, threads: 4 }, rx: LinkRxConf { buffer_size: 65535, max_message_size: 1073741824 }, tls: TLSConf { root_ca_certificate: None, server_private_key: None, server_certificate: None, client_auth: Some(false), client_private_key: None, client_certificate: None, server_name_verification: None, root_ca_certificate_base64: None, server_private_key_base64: None, server_certificate_base64: None, client_private_key_base64: None, client_certificate_base64: None }, unixpipe: UnixPipeConf { file_access_mask: None } }, shared_memory: SharedMemoryConf { enabled: false }, auth: AuthConf { usrpwd: UsrPwdConf { user: None, password: None, dictionary_file: None }, pubkey: PubKeyConf { public_key_pem: None, private_key_pem: None, public_key_file: None, private_key_file: None, key_size: None, known_keys_file: None } } }, adminspace: AdminSpaceConf { enabled: false, permissions: PermissionsConf { read: true, write: false } }, downsampling: [], access_control: AclConfig { enabled: false, default_permission: Deny, rules: None }, plugins_loading: PluginsLoading { enabled: false, search_dirs: None }, plugins: Object {} }
router-1  | 2024-06-21T12:56:01.012019Z DEBUG ThreadId(02) zenoh::net::runtime: Zenoh Rust API v93f93d2d
router-1  | 2024-06-21T12:56:01.012022Z  INFO ThreadId(02) zenoh::net::runtime: Using ZID: fca00e661bceb62e60cc864b7882c12e
router-1  | 2024-06-21T12:56:01.012026Z DEBUG ThreadId(02) zenoh::net::routing::interceptor::access_control: Access control is disabled
router-1  | 2024-06-21T12:56:01.013200Z DEBUG ThreadId(02) zenoh::net::routing::hat::router::network: [Routers network] Add node (self) fca00e661bceb62e60cc864b7882c12e
router-1  | 2024-06-21T12:56:01.013471Z DEBUG ThreadId(02) zenoh::net::routing::hat::router::network: [Peers network] Add node (self) fca00e661bceb62e60cc864b7882c12e
router-1  | 2024-06-21T12:56:01.013759Z DEBUG ThreadId(02) zenoh::net::routing::router: New Face{0, fca00e661bceb62e60cc864b7882c12e}
router-1  | 2024-06-21T12:56:01.014186Z DEBUG ThreadId(02) zenoh::net::runtime::orchestrator: Try to add listener: tcp/[::]:7447: ConnectionRetryConf { exit_on_failure: true, period_init_ms: 1000, period_max_ms: 4000, period_increase_factor: 2.0 }
router-1  | 2024-06-21T12:56:01.014287Z DEBUG ThreadId(02) zenoh::net::runtime::orchestrator: Listener added: tcp/[::]:7447
router-1  | 2024-06-21T12:56:01.014477Z  INFO ThreadId(02) zenoh::net::runtime::orchestrator: Zenoh can be reached at: tcp/10.250.2.2:7447
router-1  | Started Zenoh router with id fca0e661bceb62e60cc864b7882c12e.
router-1  | terminate called after throwing an instance of 'std::runtime_error'
router-1  |   what():  Failed to get old console mode
router-1  | [ros2run]: Aborted
router-1 exited with code 250

my entrypoint file is the following:

#!/bin/bash
set -e

# Set up ROS environment
source /opt/ros/$ROS_DISTRO/setup.bash --
exec "$@"

Operating System

OS: Ubuntu 22.04
Docker version: CE 26.1.3
Container Ros Version: Iron
RMW Zenoh version: rolling branch (commit: 7609e41)

[Yadunund]

Is this a docker specific issue? Does it also happen with deb binaries created outside of docker?

[ggari-robotnik]

Hi, Have no idea since what could happen on the host system. But I think that since I will use it in bash console the problem will be absent.

[Timple]

I had similar issues when running ros2 run rmw_zenoh_cpp rmw_zenohd& on my normal pc.

When I pop it out from the background, nodes started connecting to it again. Might be related.

[reinzor]

This also happens when I try to start the daemon via a launch file:

<launch>
  <node pkg="rmw_zenoh_cpp" exec="rmw_zenohd" output="screen" shell="true" emulate_tty="true" />
</launch>

[INFO] [rmw_zenohd-1]: process started with pid [42980]
[rmw_zenohd-1] Started Zenoh router with id 2d9a65a78571c0406d116095c0c1b422.
[rmw_zenohd-1] terminate called after throwing an instance of 'std::runtime_error'
[rmw_zenohd-1]   what():  Failed to get old console mode
[rmw_zenohd-1] Aborted (core dumped)

[CihatAltiparmak]

Hello, i am not sure if it's convenient way but i could successfuly run zenoh router in my launch by adding below part to my launch file.

router = ExecuteProcess(
    cmd=[[
        "ros2 run rmw_zenoh_cpp rmw_zenohd < /dev/tty"
    ]],
    shell=True
)

[Timple]

Actually there seems to be more issues with the whole capturing keyboard functionality.

Why not strip every keyboard processing from the code and only rely on ctrl+c?

The "press q to quit" is a nice touch, but it seems to do more harm, it could as well mention "press ctrl+c to quit".
Not sure about windows though, but it probably already has a syntax how to gracefully stop processes 🙂

[CihatAltiparmak]

Actually there seems to be more issues with the whole capturing keyboard functionality.

Why not strip every keyboard processing from the code and only rely on ctrl+c?

I strongly agree with you. As an user, i think it's unnecessary stuffs to be able to use q keyboard option while i can use ctrl+c combination.

The "press q to quit" is a nice touch, but it seems to do more harm, it could as well mention "press ctrl+c to quit". Not sure about windows though, but it probably already has a syntax how to gracefully stop processes 🙂

Unfortunately, i cannot say anything about Windows 🙂

Anyway, i have discovered that if we run router in ExecuteProcess with shell=True flag, launch creates two process, one of them is for sh shell and other one is for ros2 command. With this option, we can set stdin via sh. But at the end of the launch, signals are not handled by router and whenever i write to corresponding terminal, my contents don't seen on screen. Additionally, seems process signal transferring between parent and child process are little bit problematic in ros2/launch. Shortly, my suggestion in this issue includes some problems.

At the end, i used subprocess manually and looks like i have become successful at running router and closing it gracefully.

https://github.com/CihatAltiparmak/moveit_middleware_benchmark/blob/6cd56736d7756d31023df7ba2152893207d2258a/launch/scenario_perception_pipeline_benchmark.launch.py#L21-L65

Edit: this repo's zenoh router executable only handle SIGINT, but i send SIGTERM to router. It can be changed type of linux signal sent to router. I tested this launch in my forked rmw_zenoh.

[nkoenig]

This issue should get fixed with #261.

[clalancette]

This was fixed by #261, so closing this.