[systemd-devel] nspawn: No Return key in machinectl login?

Tobias Hunger tobias.hunger at gmail.com
Fri Jun 19 01:15:57 PDT 2015


Thanks for the reply!

I'll try to collect all requested info tonight or over the weekend.

Best Regards,
Tobias

On Thu, Jun 18, 2015 at 9:24 PM, Lennart Poettering
<lennart at poettering.net> wrote:
> On Tue, 26.05.15 21:40, Tobias Hunger (tobias.hunger at gmail.com) wrote:
>
>> This is stty -a from outside the container:
>>
>> speed 38400 baud; rows 46; columns 114; line = 0;
>> intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = M-^?;
>> eol2 = M-^?; swtch = <undef>; start = ^Q;
>> stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O;
>> min = 1; time = 0;
>> -parenb -parodd -cmspar cs8 -hupcl -cstopb cread -clocal -crtscts
>> -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl
>> -ixon -ixoff -iuclc ixany imaxbel -iutf8
>> opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
>> isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop
>> -echoprt echoctl echoke
>>
>> This is stty -a inside the nspawn-container:
>>
>> speed 38400 baud; rows 46; columns 114; line = 0;
>> intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
>> eol2 = <undef>; swtch = <undef>; start = ^Q;
>> stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O;
>> min = 1; time = 0;
>> -parenb -parodd -cmspar cs8 hupcl -cstopb cread -clocal -crtscts
>> -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl
>> -ixon -ixoff -iuclc -ixany -imaxbel iutf8
>> opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
>> isig icanon -iexten echo echoe echok -echonl -noflsh -xcase -tostop
>> -echoprt -echoctl echoke
>>
>> The difference is:
>> eol, eol2, -icrnl -ixany -imaxbel iutf8 -iexten -echoctl
>
> Sorry for the late reply...
>
> Hmm, I think the most interesting info would actually be to see stty
> -a from a working instance, and from a non-working
> instance. I.e. start the container, log into it, type "stty -a" command when
> everything works, and when it doesn't, and let me know the diff of it.
>
> Also, right after doing the "stty -a" in the container, please run the
> same commands on the host, in a seperate xterm, but connect to the
> host side container tty using "stty -a -F /dev/pts/xyz", where
> /dev/pts/xyz is the pts that nspawn itself is running on.
>
> Or to explain it in more steps:
>
> a) open an xterm of some form
>
> b) type "tty" into it, and remember the pty name it responds. It
>    should be something like "/dev/pts/xyz".
>
> c) now run systemd-nspawn inside the xterm, and login there, then type
>    "stty -a" in it, and save the output that command generated
>    somewhere.
>
> d) now, leave everything as it is now, open a second xterm. In it run
>    "stty -a -F /dev/pts/xyz", replacing "/dev/pts/xyz" with the pty
>    name from step b) and save the output somwhere.
>
> Then, close both xterms. Do these steps once for a container where
> things work, and once for a container where things are borked. Then
> let me know the diffs between the working and non-working outputs from
> both runs of c), as we as the diffs between the working and
> non-working outputs from both runs of d).
>
> Make sure you take the stty snapshots at the exact same states each
> time, because shells and so on tend to toggle some bits of it
> depending on whether they are in the fg or not...
>
> Also, it would be good, to check if different xterm implementations
> (gnome, kde, original xterm) behave differently.
>
> Lennart
>
> --
> Lennart Poettering, Red Hat


More information about the systemd-devel mailing list