Ctrl + C signal not working in v0.4.2

[junxy]

need some configure?

# ssh client ,with iTerm2 Build 2.1.4
$ ssh -V
OpenSSH_6.9p1, LibreSSL 2.1.8

$ sudo ros -v
ros version v0.4.2

[ibuildthecloud]

@junxy I've seen this issue too, not terribly sure what causes it. CTRL+C works fine for me, but I have seen times where it doesn't but I've never reproduced. I run Linux, so I'll try your setup on a Mac and see if it happens to me.

[robbertkl]

Have the same issue here, but only in the (default) ephemeral console. In debian-console CTRL+C works as expected. Compared stty -a on both, but no differences. So it might have something to do with busybox.

A quick test shows that in the ephemeral console:

• CTRL+C is not working
• CTRL+D is working
• CTRL+L is not working
• CTRL+Z is not working

Strange detail is that when you start ash, CTRL+C and CTRL+L do seem to be working, at least while you're still typing in the shell. When starting a sleep 10 within ash however, CTRL+C (or CTRL+Z for that matter) won't work.

[ibuildthecloud]

I've reproduced this also, there is something up with the default console and the signal handling. CTRL+C will work for top, but no tail. Doesn't make a lot of sense, but I'm looking into it.

[quantverse]

+1, same issue here...very annoying

Interesting: CTRL+C works fine on instance based on rancher-os 0.4.1, even after upgraded to 0.4.2 using ros update

on instance with fresh 0.4.2 CTRL+C does not work (at least in ping and tail -f)

[robbertkl]

Do you use debian-console or ubuntu-console on the first instance? Was it originally installed with 0.4.1, or later upgraded to 0.4.1 (and subsequently 0.4.2)?

[quantverse]

Both instances use the ephemeral (busybox) console and never used any other console.
The 0.4.1 instance has been originally installed with 0.4.1.

[fascinatedcow]

Same issue here. Fresh, disk install of 0.4.2 in virtualbox 4.3 on Linux.

[michaellopez]

I upgraded with sudo ros os upgrade to 0.4.2 from 0.4.1. Now I cannot use CTRL + C in 0.4.2. Works fine in 0.4.1. I have never configured anything regarding console, so I'm using the default I guess (rancher/os-console:v0.4.2)

[michaellopez]

Trying it again I could use CTRL + C on a machine upgraded to 0.4.2 from 0.4.1. Meaning the opposite of my previous try. Maybe there is a race condition somewhere? A few reboots might be what made it work again?

[robbertkl]

Just noticed the same thing:

I installed 2 identical machines, both with a fresh 0.4.2, no custom configuration, default ephemeral console. On machine A CTRL+C worked, on machine B it didn't. Logging out and back in with SSH does not change this. However, after a reboot the situation was reversed. Some more reboot tests confirmed it's "random" if a booted machine will accept CTRL+C in the console.

It really looks like some kind of race condition at boot time or when starting the rancher/os-console container. Also note that running sudo su - gets you into a shell where CTRL+C is always working.

[datawolf]

+1
Same issue here.

when i start RancherOS, run the folloing command ping -c 2 xxx.xxx.xxx.xxx, it will block, and Ctrl+C can not work.

[ibuildthecloud]

I have to say, this issue is driving me nuts. If you do sudo system-docker restart console it will often fix it. There is some race condition in the initialization of the console that is causing an issue here. Very very odd. I can't fathom what it could be that would universally mess up CTRL+C. CTRL+C doesn't work on both the host console and SSH. It is as though the PTY subsystem is in an odd state, but again how, why.... I will fix this because it irritates me so much.

[robbertkl]

Just checked stty -a, but unfortunately it shows no differences between a working and messed up CTRL+C. No clue there.

[deniseschannon]

This is now working about 75% of the time.

[kyzh]

I might have found the root cause for this signal problem.
The wrong signal mask set to respawn all the way down to bash look like a go 1.5.x problem.
A workaround would be to use 1.4 , the fix seems to be in go 1.6.

It is explained could in this issue, this patch and this discussion
It is reported as a fix for consul-template

I did do a quick script to check the signal mask for a given pid
I don't know how to recreate an AMI 😞 so I didn't test with go 1.6 myself

[ryansch]

@kyzh You can boot the latest rancherOS in AWS and then use ros install to get it installed to an EBS volume. Create an AMI with a snapshot of that volume.

Took me a while to figure out that's all that was involved.

If you want more control you can run an install from a container. Here's an example from when I was testing an RC release:

sudo system-docker run --privileged -it --entrypoint=/scripts/set-disk-partitions rancher/os:v0.4.3-rc2 /dev/xvdf

sudo system-docker run --privileged -it -v /home:/home -v /opt:/opt rancher/os:v0.4.3-rc2 -d /dev/xvdf -t amazon-ebs-hvm -c $(pwd)/cloud-config.yml

Contents of cloud-config.yml:

#cloud-config
rancher:
  cloud_init:
    datasources:
      - ec2

[deniseschannon]

Updating the version of Go has seemed to fix it in current master.

Will be in v0.4.4