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

Fix ^C handling #178

Open
tych0 opened this issue Jun 28, 2021 · 6 comments
Open

Fix ^C handling #178

tych0 opened this issue Jun 28, 2021 · 6 comments

Comments

@tych0
Copy link
Collaborator

tych0 commented Jun 28, 2021

Our outer userns exec wrapper doesn't forward ^C to the inner one, so things don't correctly get killed on ^C. We need to do something like what's in container.go:Execute() i guess.

@smoser
Copy link
Contributor

smoser commented Jul 29, 2021

As reported by @raharper and I, if you ctrl-c while stacker is running and has launched a container, it crashes gnu screen and all gnu screen processes. Yikes.

@tych0
Copy link
Collaborator Author

tych0 commented Jul 29, 2021

That almost seems like a gnu screen bug? in tmux it just orphans the thing and dooesn't actually ^C :)

@mikemccracken
Copy link
Contributor

weird. as a data point, I use gnu screen all the time and am pretty sure I've ^C'd a stacker build a few times.
never got nuked like that. I'm using bionic, with 5.4.0 though...

tych0 added a commit to tych0/stacker that referenced this issue Aug 10, 2021
as of 5ffa9bd ("Reexec stacker build/recursive-build inside a user
namespace") we have a wrapper process that is the one that actually
receives the signal from the shell, and promptly ignores it. let's forward
relevant signals to the child process...

perhaps we should commonize this somehow with the stuff that's in
container.go, but this is good enough for now.

it would also be good to figure out how to test some of this, but i played
around with bats, and various incantations of subshell job forking didn't
work for me. e.g.:

~/packages/stacker fix-ctrlc cat test/ctrlc.bats
load helpers

function setup() {
    stacker_setup
}

function teardown() {
    cleanup
}

@test "stacker responds to SIGTERM" {
    cat > stacker.yaml <<EOF
test:
    from:
        type: oci
        url: $CENTOS_OCI
    run: |
        sleep 100s
EOF
    (stacker build) &
    pid=$!

    # let it get some progress; maybe this is still in go code, mabye it's in
    # the container's sleep, but it's somewhere interesting at least
    sleep 5s
    kill -SIGINT $pid
    wait $pid
}

and this at least fixes the problem, so let's just add it.

Closes project-stacker#178

Signed-off-by: Tycho Andersen <[email protected]>
@tych0 tych0 closed this as completed in 7113229 Aug 10, 2021
@tych0
Copy link
Collaborator Author

tych0 commented Sep 20, 2021

I don't think (?) this is fixed. It's "better" now, but I've still seen stacker kill tmux sessions.

@tych0 tych0 reopened this Sep 20, 2021
@smoser
Copy link
Contributor

smoser commented Oct 20, 2021

I don't think (?) this is fixed. It's "better" now, but I've still seen stacker kill tmux sessions.

i dont think fixed either. :-(. its hard to remember to not hit ctrl-c if stacker is running.

@tych0
Copy link
Collaborator Author

tych0 commented Oct 20, 2021

Yeah, any sleuthing about what's going on is much appreciated. I don't really understand what's happening here.

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

No branches or pull requests

3 participants