^C does not send a SIGINT to the server

[JohnB17]

Is there an existing issue for this?

• I have searched the existing issues before opening this issue.

Current Behavior

Using ^C as the stop command does not send a SIGINT to the server, but ^^C does.

Expected Behavior

^C as the stop command should send a SIGINT to the server.

Steps to Reproduce

Set the stop command as ^C then try to stop the server

Panel Version

1.6.2

Wings Version

1.5.1

Error Logs

None

[parkervcp]

Pretty sure this is the eval vs exec issue.

I still think we could change the way containers start with the entrypoint and commands.

[trenutoo]

Pretty sure this is the eval vs exec issue.

I still think we could change the way containers start with the entrypoint and commands.

Tested this and it's indeed caused by the Docker image entrypoint startup eval and works fine with exec, as discussed in the past at #3042 and parkervcp/images#73

Some eggs have script-like startups that the exec can't parse properly (ex. Discord and ark eggs), I think we can make the rest of the images and eggs work with it.

Pretty sure @matthewpi was working on changing how the startup args are passed to Wings?

[JohnB17]

Maybe Wings could check if the stop command is a specific set of text such as "SIGINT" and just kill the container if that is what the stop command is, if not just run the provided command.

[matthewpi]

Sadly, we can't actually send a SIGINT to the process from wings, only Docker itself can (aka ContainerStop). If you put ^SIGINT as the stop command you will see Error response from daemon: Invalid signal: interrupt. When you put ^^C or ^{anything other than C, SIGABRT, SIGINT, SIGTERM} you are sending a kill signal. (ref)

However, ContainerStop sends a proper SIGINT signal, it's the entrypoints of eggs that use eval or call another script that have this problem.

The eval problem is something that I plan to work around in v2, but this is an egg/image level problem, not a bug with Wings or the Panel.