Bug 1695690

It's got to be one of these:
https://wiki.gnome.org/Apps/Terminal/FAQ#Terminal_fails_to_start

My first instinct is to suspect that the locale isn't set correctly.

ping

Do you have a /root/anaconda-ks.cfg on your system? If so, may I see it?

To answer the original needinfo, the errors in the linked https://wiki.gnome.org/Apps/Terminal/FAQ#Terminal_fails_to_start don't seem to apply. None of them has a "timeout" in the error message.

Furthermore, as I pointed in the original issue, the problem occurs only with tigervnc.

Regarding the locale (client side), here is what I currently have:

LANG=""
LC_COLLATE="C"
LC_CTYPE="UTF-8"
LC_MESSAGES="C"
LC_MONETARY="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_ALL=

That does not mean that's what tigervnc sets up. I need to see what is reported within xterm.

Unfortunately, the beaker machines tend to be a bit crowded, and I did not want to reserve one for what I considered really low priority. Given the needinfo is now from a customer, I asked for a short-term loaner. Will get back to you when I have it.

Thanks for the information, Christophe!

(In reply to Christophe de Dinechin from comment #6)
> To answer the original needinfo, the errors in the linked
> https://wiki.gnome.org/Apps/Terminal/FAQ#Terminal_fails_to_start don't seem
> to apply. None of them has a "timeout" in the error message.

Yes, that's strange. I wonder if something has changed in the underlying D-Bus layer, or it could just be that the remote VM was too slow and the actual failure got morphed into a timeout.

I think the systemd journal would have more details:
$ journalctl _EXE=/usr/libexec/gnome-terminal-server

Given the locale information further below, I'd expect to see:
Non UTF-8 locale (ISO-8859-1) is not supported!

Anyway, this is the relevant entry from the FAQ:
https://wiki.gnome.org/Apps/Terminal/FAQ#Exit_status_8

> Furthermore, as I pointed in the original issue, the problem occurs only
> with tigervnc.

> Regarding the locale (client side), here is what I currently have:
> 
> LANG=""
> LC_COLLATE="C"
> LC_CTYPE="UTF-8"
> LC_MESSAGES="C"
> LC_MONETARY="C"
> LC_NUMERIC="C"
> LC_TIME="C"
> LC_ALL=

Now we need to figure why the locale is set to "C". It should be something UTF-8.

What does your /etc/locale.conf look like? What does /root/anaconda-ks.cfg look like?

Another question that's worth asking is whether there's a working user or session D-Bus instance at the point when you are trying to launch GNOME Terminal. It's hopeless to try to use GNOME Terminal without working D-Bus, because the application has a client-server architecture. The real application (or at least the bulk of it) is in the /usr/libexec/gnome-terminal-server binary. The /usr/bin/gnome-terminal binary is a very thin launcher that sends a D-Bus message to the server to request it to open a new tab or window.

You can use something like this to check D-Bus:
  $ gdbus introspect --session --dest org.freedesktop.DBus --object-path /org/freedesktop/DBus

(In reply to Debarshi Ray from comment #7)
> 
> Yes, that's strange. I wonder if something has changed in the underlying
> D-Bus layer, or it could just be that the remote VM was too slow and the
> actual failure got morphed into a timeout.

Well, this bug is quite old, and so I have to dig in old memory.
At the time, I was trying to make a demo of video streaming with SPICE.
The network between my home and the beaker machine was indeed extremely
slow and unreliable (problem being on my side), so I tried to do some
setup with VNC to see if the problem was with SPICE or just the network.


Now, I have both Linux and macOS machines at home. I see no information
in the bug about using macOS, which I believe I would have mentioned.
I'm pretty sure I tried both at the time, and saw the same issue in
both cases. I typically don't file a bug if I only see the problem on
macOS.

I'm giving this context because in my previous e-mail, I incorrectly
reported "locale" from a macOS terminal which had lost the connexion
to the Linux machine I was looking at.
 
> I think the systemd journal would have more details:
> $ journalctl _EXE=/usr/libexec/gnome-terminal-server

I will share that information if I get a beaker machine in the same lab.

> 
> Given the locale information further below, I'd expect to see:
> Non UTF-8 locale (ISO-8859-1) is not supported!

Indeed, from Linux, I get:

LANG=en_US.UTF-8
LC_CTYPE=C.UTF-8
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=


But that locale is clearly not propagated over ssh -Y, as this example shows. The macOS locale is the one I listed, the Linux locale is the en_US.UTF-8 one. So that means I need to connect to a machine provisioned the same way to check the locale that matters.

> 
> Anyway, this is the relevant entry from the FAQ:
> https://wiki.gnome.org/Apps/Terminal/FAQ#Exit_status_8
> 
> > Furthermore, as I pointed in the original issue, the problem occurs only
> > with tigervnc.
> 
> > Regarding the locale (client side), here is what I currently have:
> > 
> > LANG=""
> > LC_COLLATE="C"
> > LC_CTYPE="UTF-8"
> > LC_MESSAGES="C"
> > LC_MONETARY="C"
> > LC_NUMERIC="C"
> > LC_TIME="C"
> > LC_ALL=
> 
> Now we need to figure why the locale is set to "C". It should be something
> UTF-8.

Again, my bad, shared a macOS locale by mistake.

I do not believe the ssh -Y in the initial report was from a macOS machine because of the context for that bug report (making a demo of SPICE, which required screen capture, which I would certainly not do on a macOS desktop for a RHEL demo ;-)


> What does your /etc/locale.conf look like? What does /root/anaconda-ks.cfg
> look like?

Let me know if you are interested in the one client-side. Since ssh -Y experimentally does not propagates the locale from macOS to Linux, I suspect it might also not propagate it from Fedora to RHEL 8, but I need to test that.

I am still interested in whether something gets logged in the systemd journal:
  $ journalctl _EXE=/usr/libexec/gnome-terminal-server

... whether you have a working session/user D-Bus instance:
  $ gdbus introspect --session --dest org.freedesktop.DBus --object-path /org/freedesktop/DBus

... and what your /root/anaconda-ks.cfg and /etc/locale.conf look like.

Sorry, I reserved a beaker machine to re-do that test, then ran into issues that ultimately proved that I could not correctly provision it with the right OS, then went on PTO. I will try to get back to it this week.

I am going to close this.

We already established (see comment 7) that the locale was set to "C", and, by design,GNOME Terminal doesn't support non-UTF-8 locales.

We kept the bug open because I was curious how Beaker managed to install a non-UTF-8 system, because that's really not what's supposed to happen. However, as interesting as that question is, ultimately it's not a gnome-terminal bug because it's working as intended.

If we ever manage to gather more details about Beaker, we should file a bug against Anaconda or Beaker or some such component.

*** This bug has been marked as a duplicate of bug 1699369 ***