zsh inside systemd-nspawn and Ctrl+C

zsh inside systemd-nspawn and Ctrl+C

[Moritz Bunkus]

[-- Attachment #1: Type: text/plain, Size: 2729 bytes --]

Hey,

Summary: I'm running into the problem that Ctrl+C stops working when I
run zsh inside a container via systemd-nspawn.

Background: I've been using chroots into full distribution trees in
order to build packages for several Linux distributions without running
full-fledged virtual machines. It basically boiled down to bind-mounting
a couple of directories and running »chroot /bin/zsh« inside the correct
directory.

For several technical reasons I'm trying to switch to using
systemd-nspawn. systemd-nspawn is setting up a container for the whole
thing (meaning various namespaces and control groups) similar to
lxc-start from lxc or OpenVZ. I don't run a full init inside that
container but solely /bin/zsh.

Now my problem. With the older method (chrooting) I could use Ctrl+C
properly from inside the chrooted zsh. Meaning typing something and
hitting Ctrl+C would abort the current line and give me a new pristine
prompt.

Not so with systemd-nspawn'd zsh: here Ctrl+c does nothing at all.

However, if I run the very same systemd-nspawn with bash instead of zsh
then bash will recognize Ctrl+C and act upon it properly.

Some more information on what I've tried:

- »stty -a« from systemd-nspawn'd zsh correctly shows »intr = ^C«

- Running »cat« from systemd-nspawn'd zsh and hitting Ctrl+C prints the
  characters »^C« but cat is not aborted and keeps running.

- Changing the interrupt key to Ctrl+X from systemd-nspawn'd zsh with
  »stty intr \^X« makes Ctrl+X not do anything anymore – just like
  Ctrl+C before that »stty intr…«.

- The same happens if I run zsh with --no-rcs.

- The same happens running ssh'ed in from another machine and from
  inside konsole running in a local X server; both cases use different
  TERM environment variables (»putty-256color« for the ssh case and
  »xterm« for the konsole/X case).

The actual command line I'm using is something like the following:

systemd-nspawn --directory=/other-linux/64/debian/jessie \
  --machine=64-debian-jessie --tmpfs=/var/lock \
  --setenv=SHELL=/bin/zsh5 --setenv=HOME=/root --user=root \
  -- /bin/zsh5 --no-rcs

This is a stripped-down version that I've confirmed to not to work.

zsh on the parent: 5.0.7; zsh inside the container: 5.0.7 (but I've
confirmed this with several older zsh versions as well, e.g. Debian
wheezy's 4.3.17).

Any ideas how I might continue debugging this issue? At this point I
don't even have an idea who the culprit might be (zsh? systemd-nspawn?
Configuration files?), not to mention how to get it working.

I'd appreciate any insight and will gladly provide more information if
necessary.

Thanks.

Kind regards,
mosu

[-- Attachment #2: Type: application/pgp-signature, Size: 181 bytes --]

Re: zsh inside systemd-nspawn and Ctrl+C

[Bart Schaefer]

On Feb 3,  1:34pm, Moritz Bunkus wrote:
}
} Summary: I'm running into the problem that Ctrl+C stops working when I
} run zsh inside a container via systemd-nspawn.

There was some discussion in December about a potentially related issue.
http://www.zsh.org/mla/workers//2014/msg01769.html

If I understand this correctly, the change to process group acquisition
that was discussed in that thread might also apply in your case.

Re: zsh inside systemd-nspawn and Ctrl+C

[Moritz Bunkus]

[-- Attachment #1: Type: text/plain, Size: 449 bytes --]

Hey,

thanks for the information, Bart. I've built zsh 5.0.7 with both patches
mentioned in that thread both on the host OS and inside the environment
I'm spawning into. Unfortunately it doesn't fix the issue.

Adding some debug output shows that GETPGRP() returns 1 anyway, so the
patch doesn't change the behavior for my use case.

Is there anything else I can try? Would an strace output of the whole
systemd-nspawn help you?

Kind regards,
mosu

[-- Attachment #2: Type: application/pgp-signature, Size: 181 bytes --]