Wings: Fix stoplogic

[QuintenQVD0]

Changes

• Instead of ContainerKill we use ContainerStop
• This takes 3 args, the ctx, the container id and the container.StopOptions what takes a timeout (as an int ) and a signal as a string
• NEEDS: https://github.com/pelican-dev/panel/pull/407

The signal must be a string so "SIGTERM" but we used to pass to syscall.SIGTERM and trim some parts but that does not work. so in the function, all incoming signals are converted to signals in string format. They also get matched with their corresponding timeout. What means for any signal the default timeout before it gets killed is 10 seconds. So:

1. The container gets the signal
2. it sends the signal to the container
3. if it exitis in those 10 seconds then it will just continue
4. if not after 10 seconds, SIGKILL is sent

The timeout is 0 for os.kill as that is what the kill button sends and then it should stop immediately .

this is combined with my panel PR so ^C send SIGTERM.

This also makes wine eggs not need anymore for ^^C but wine can not wait it will just direct exit (how it also does it with ^^C)

you can also now do as stop ^SIGINT, ^SIGTERM, ^SIGABRT what will be converted in to a signal.

This would stop the need for tini but it still can be usefull.

Example

mordhau:

Tested with the panel patch with ^C and ^SIGTERM

[QuintenQVD0]

the docker default is SIGTERM and a timeout of 10seconds? and sigkill must happen inimitably ?

and that setting of sig is needed as you must pass a string and not a syscall signal directly?

[RMartinOscar]

There's no use to match case for os.Kill when the consequence is the same as the default case

[QuintenQVD0]

There's no use to match case for os.Kill when the consequence is the same as the default case

I changed it.

[QuintenQVD0]

Converted to a draft as their is something wrong with the wings or panel logic itself

[QuintenQVD0]

IF you revert the this commit: https://github.com/pelican-dev/wings/commit/7bf9f6a9d0f8061bcdbcceeb34372d0f32ad25e6

then stop works but kill is broken

[RMartinOscar]

This may resolve it

[QuintenQVD0]

This may resolve it

I worked with him and no. Their is something weong with our panel reporting container statuses. I can't realy point to what exactly but this pr does the same just a diffrend way.