vi ( Vitaly Shukela )

There are many ways to specify both ENTRYPOINT and CMD in Dockerfile, docker-compose and command line. Some of them (namely, without formal JSON array notation) involve automatic wrapping the whole script in sh -c, known as shell form. And that might be the reason some tools in docker handle Ctrl-C out-of-the-box as they should.

ratijas

comment created time in a day

issue commentvi/websocat

Server mode does not respond to Ctrl-C (until it handles any client)

How interesting. Never thought docker would introduce that kind of problems.

I guess it works only because bash handles SIGCHLD when child dies?

I don't know how it is related to SIGCHLDs

I mean, child handles Ctrl-C and thus exits. When that happens, parent process (bash) receives a signal SIGCHLD, and since that was its only child process, it also exits while propagating exit status. At least, that's my understanding of things.

ratijas

comment created time in a day

issue commentvi/websocat

Server mode does not respond to Ctrl-C (until it handles any client)

Hmm... I don't remember ever running into that. Maybe I was just lucky until today.

But what about --entrypoint=/bin/bash? I guess it works only because bash handles SIGCHLD when child dies?

Init processes don't typically terminate on signals

And what exactly means that line of your? Is there some code like if pid != 1 { handle_sigint() } somewhere in... runtime's default handler? operating system kernel?

ratijas

comment created time in a day

issue commentvi/websocat

Server mode does not respond to Ctrl-C (until it handles any client)

That sounds logical from the implementation point of view, but practically most tools in docker used to terminate on Ctrl-C regardless of being init or not.

ratijas

comment created time in a day

issue openedvi/websocat

Server mode does not respond to Ctrl-C (until it handles any client)

Summary

Websocat does not respond to Ctrl-C in docker. It can't be stopped — only killing its container helps.

~It claims to start listening on port, but the not even telnet is able to connect to that port, nor it is listed in lsof -i output. (yep, I run docker with -p 1234:1234 alright).~ (See partial solution below)

Solution (partial)

Part of my problem is that I blindly copied websocat -s 1234 example from the README. Indeed, websocat is up and running, but listening on container-local interface 127.0.0.1 which is not visible on the host machine. But Ctrl-C is not working yet.

$ docker run --rm -p 1234:1234 solsson/websocat -s 1234
Listening on ws://127.0.0.1:1234/
^C^C^C

-- no reaction whatsoever.

Once I run docker exec inside a running websocat container, I am able to connect to a server from an instance of websocat client:

$ docker exec -it 97c7b0415b7c /bin/bash
root@97c7b0415b7c:/# websocat ws://127.0.0.1:1234/
hello

-- and it works as expected: server prints the same message on its terminal.

After handling even a single message from a client, server starts responding to Ctrl-C.

$ docker run --rm -p 1234:1234 solsson/websocat -s 1234
Listening on ws://127.0.0.1:1234/
^C^C^Chello
^C
$ # OK, we are cool

created time in a day

startedvi/websocat

started time in a day

startedvi/websocat

started time in a day

startedvi/websocat

started time in 2 days

startedvi/websocat

started time in 2 days

startedvi/websocat

started time in 3 days

startedvi/websocat

started time in 3 days

startedvi/websocat

started time in 3 days

startedvi/websocat

started time in 3 days

startedvi/websocat

started time in 3 days

startedvi/websocat

started time in 3 days

startedvi/websocat

started time in 3 days

fork chouaibhm/websocat

Command-line client for WebSockets, like netcat (or curl) for ws:// with advanced socat-like functions

vi/websocat chouaibhm/websocat

fork in 3 days

startedvi/websocat

started time in 3 days

startedvi/virtual_touchscreen

started time in 3 days

startedvi/websocat

started time in 4 days

startedvi/imlib2-bpg

started time in 4 days

startedvi/websocat

started time in 4 days

startedvi/websocat

started time in 4 days

startedvi/tcptunnelchecker

started time in 5 days

startedvi/websocat

started time in 5 days

startedvi/websocat

started time in 5 days