Description of problem:
After yum update to RHEL-7.6-20180612.n.1 nightly build, which includes gnome-terminal-3.28.2-2.el7.x86_64, I can't create a usable gnome-terminal.
The window is created, a bash process is created, but the /dev/pts/<N> device does not exist, there is no bash prompt in the gnome terminal window, and the bash process is a zombie.
Version-Release number of selected component (if applicable):
How reproducible: 100%
Steps to Reproduce:
1. yum update to RHEL-7.6-20180612.n.1 from an earlier 7.6 nightly
I didn't try a clean install.
2. Log in and select terminal from gnome shell application menu
1. Terminal window is created
2. No bash prompt in created terminal window
I don't know if it's relevant, but I was able to install terminator from the epel repo and it is able to successfully create usable terminal windows.
Have you restarted your session (Alt+F2 r <Enter>)? Or rather reboot to be sure?
I saw that too but after session restart it works fine.
OK it is back, seems vte is incredible slow in displaying prompt.
When this occurs, the folowing message is logged in /var/log/messages:
Jun 13 15:43:54 localhost journal: void vte_terminal_watch_child(VteTerminal*, GPid): assertion 'impl->m_pty != NULL' failed
Just to narrow things down a bit, what happens if you install the vte291-devel package and try the toy /usr/bin/vte-2.91 program? Does it give you working shell prompt?
Installed vte291-devel, tried some simple commands. Seems to be working well for me.
In my case it behaves randomly, so the same behaviour as the gnome-terminal
(In reply to Michal Odehnal from comment #6)
> Installed vte291-devel, tried some simple commands. Seems to be working well
> for me.
And as I thought it was working, few restarts later it is not working again. Few restarts later it is working again.
Still hard failure for me.
I installed vte291-devel (and all the other packages it depends on) and rebooted.
I'm also seeing the following in /var/log/messages:
Jun 13 11:09:38 rhel-vm01 journal: void vte_terminal_watch_child(VteTerminal*, GPid): assertion 'impl->m_pty != NULL' failed
(In reply to Debarshi Ray from comment #5)
> Just to narrow things down a bit, what happens if you install the
> vte291-devel package and try the toy /usr/bin/vte-2.91 program? Does it give
> you working shell prompt?
Sorry, I missed the part about /usr/bin/vte-2.91
Indeed /usr/bin/vte-2.91 works and gets me a shell prompt.
I do get this message though:
(Terminal:3803): GLib-GIO-CRITICAL **: 11:44:33.549: g_dbus_proxy_new_sync: assertion 'G_IS_DBUS_CONNECTION (connection)' failed
(In reply to Lenny Szubowicz from comment #10)
> (In reply to Debarshi Ray from comment #5)
> > Just to narrow things down a bit, what happens if you install the
> > vte291-devel package and try the toy /usr/bin/vte-2.91 program? Does it give
> > you working shell prompt?
> Sorry, I missed the part about /usr/bin/vte-2.91
> Indeed /usr/bin/vte-2.91 works and gets me a shell prompt.
> I do get this message though:
> (Terminal:3803): GLib-GIO-CRITICAL **: 11:44:33.549: g_dbus_proxy_new_sync:
> assertion 'G_IS_DBUS_CONNECTION (connection)' failed
I also see the same intermittent behavior as reported in comment 7.
/usr/bin/vte-2.91 sometimes also ends up with a window with no shell prompt.
When that happens, I see the following:
Terminal:3330): Vte-CRITICAL **: 09:41:58.736: void vte_terminal_watch_child(VteTerminal*, GPid): assertion 'impl->m_pty != NULL' failed
Just a quick update. I can reproduce it too, and I am looking into it. It seems related to the gnome-pty-helper code, because it doesn't happen if you build without --enable-gnome-pty-helper.
(--enable-gnome-pty-helper needs to be explicitly passed because it's not there by default. That's why I didn't notice it when testing the rebased patches. Sorry about that.)
For some reason, VteTerminal was getting a "hang up" (ie. G_IO_HUP) while polling the pseudo-terminal master device (ie. the end of the pseudo-terminal pipe / device pair that's in the UI process), and this was only happening when using gnome-pty-helper and vte_terminal_spawn_async. Not using gnome-pty-helper or using vte_terminal_spawn_sync would not cause this bug.
The move from vte_terminal_spawn_sync to vte_terminal_spawn_async happened between RHEL 7.4 and 7.6. So running gnome-terminal from RHEL < 7.6 with newer vte291 would not cause this bug.
The reason for this is that the asynchronous code path starts polling the pseudo-terminal master device a little too early in the sequence. When gnome-pty-helper is used, the helper is in charge of creating the pseudo-terminal device pair, and it closes its copies of the file descriptors after sending them to the main UI process. I believe that polling the master device immediately after receiving it from the helper can leave it vulnerable to a race condition where the helper closes its copies after the poll has been initiated.
Instead, we should start polling after the child process has been forked and exec-ed. Since the child would keep its copy of the pseudo-terminal slave device open, having the helper close its copy after that wouldn't matter. This is also what the synchronous code path does, which we have been using without any problem so far.
(In reply to Debarshi Ray from comment #15)
> Building vte291-0.52.2-2.el7:
quickly tested in wm, works fine for me, thanks rishi
Works for me as well. Thanks! -Lenny.
terminal works fine for long time, moving to VERIFIED
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.