Has anyone else run into this? I've never before run into this problem, not any version of Server or Workstation. Just cloud, and I've run into it several times in just a few days.
I'm using public-key authentication to ssh into a Fedora 23 Cloud Atomic ISO installation upgraded to 23.29. This works most of the time, until it doesn't and then I always get this.
[chris@f23m ~]$ ssh chris@10.0.0.15 PTY allocation request failed on channel 0
If I happen to have an existing login available, even if I restart sshd the problem isn't fixed. The only fix I've found so far is a reboot which is more than a bit disruptive. Any ideas?
In the journal host side, it records a bunch of audit stuff, but three lines that seem particularly relevant yet not illuminating:
Dec 12 12:37:10 f23a.localdomain audit[1]: USER_AVC pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='Unknown permission start for class system exe="/usr/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal=?' [snip] Dec 12 12:27:25 f23a.localdomain sshd[2029]: error: openpty: No such file or directory Dec 12 12:27:25 f23a.localdomain sshd[2032]: error: session_pty_req: session 0 alloc failed
systemd-222-8.fc23.x86_64
I'd file a bug but I don't even know what to file it against. The full journal output is here: http://fpaste.org/3001
I have a lead.
I'm still working on this bug: https://bugzilla.redhat.com/show_bug.cgi?id=1290691
And when I do this: [root@f23a ~]# docker run --net=host --pid=host -v /dev:/dev --privileged=true fedext /usr/sbin/iotop -d3 Traceback (most recent call last): File "/usr/sbin/iotop", line 17, in <module> main() File "/usr/lib/python2.7/site-packages/iotop/ui.py", line 631, in main main_loop() File "/usr/lib/python2.7/site-packages/iotop/ui.py", line 621, in <lambda> main_loop = lambda: run_iotop(options) File "/usr/lib/python2.7/site-packages/iotop/ui.py", line 508, in run_iotop return curses.wrapper(run_iotop_window, options) File "/usr/lib64/python2.7/curses/wrapper.py", line 22, in wrapper stdscr = curses.initscr() File "/usr/lib64/python2.7/curses/__init__.py", line 33, in initscr fd=_sys.__stdout__.fileno()) _curses.error: setupterm: could not find terminal
After that traceback, any attempt to ssh to the host is munged as previously described. So somehow that docker command puts the host in a state where subsequent ssh attempts fail.
Stopping docker and sshd, then starting sshd then docker, doesn't help. I still can't login.
So is this a docker bug?
Chris Murphy
On Sat, Dec 12, 2015 at 1:31 PM, Chris Murphy lists@colorremedies.com wrote:
I have a lead.
I'm still working on this bug: https://bugzilla.redhat.com/show_bug.cgi?id=1290691
And when I do this: [root@f23a ~]# docker run --net=host --pid=host -v /dev:/dev
OK perfect. It's user error. The -v /dev:/dev wasn't meant to be literal, but rather /dev/sda:/dev/sda, or whatever. So if I stop doing that nonsense, the login breakage no longer happens.