# gnome-terminal & xfce terminal closes immediately



## kobodjo (Feb 6, 2014)

Hi, 

I just installed FreeBSD 10 in Virtualbox (host is Windows 8).

I have an issue with gnome-terminal (when I use gnome) and xfce-terminal (when I use xfce4).
I can open one terminal window, but when I open a second one, it briefly opens and then closes immediately.

Any clues?


----------



## SirDice (Feb 6, 2014)

Can you start the second terminal on the command line of the first? Are there any error messages printed?


----------



## kobodjo (Feb 6, 2014)

Hi, 
I just tried that. 
The terminal window pops up and immediately disappears, and I get back to the prompt (in the first terminal window) without any error messages.

Greetings.


----------



## rliegh (Mar 22, 2014)

kobodjo said:
			
		

> Hi,
> I just tried that.
> The terminal window pops up and immediately disappears, and I get back to the prompt (in the first terminal window) without any error messages.
> 
> Greetings.


I'm experiencing this too on FreeBSD 10/i386, I"ve tried installing gnome-terminal and it has the same behavior (a window pops up and quickly disappears). 
No error messages, no core file.

I'm starting X with startx, not with xdm or any other display manager.


----------



## wblock@ (Mar 22, 2014)

Maybe a missing font or directory?  Does `xfce4-terminal -e 'sleep 10'` give time to see an error?


----------



## rliegh (Mar 22, 2014)

wblock@ said:
			
		

> Maybe a missing font or directory?  Does `xfce4-terminal -e 'sleep 10'` give time to see an error?


It creates a window, but nothing appears in the window -no errors or anything.


----------



## user00 (Mar 31, 2014)

I am having the same problem only in one installation of FreeBSD 10: 32bit running on a P4 machine with 768MB of RAM.
What happened was: I opened `gnome-terminal`, then edited profile settings to change default window size to 160x60 and color scheme to green on black, then hit Ctrl-D and since then it opens up and immediately closes down. xterm works fine. Not sure what to blame, as prior to a profile change gnome-terminal worked absolutely fine.

Edit: This is getting worse  I just tried starting a 2nd gnome-terminal and it closed. There were no changes to the terminal configuration, but I installed and removed a few packages that should not have anything to do with it (Sane).


----------



## user00 (Apr 1, 2014)

By method of trial and error I just found that terminal closes immediately only when profile option 'Update login records' is turned on.
Now that I turned it off, 2nd copy does not close immediately anymore.
I do not believe I changed this setting since installing FreeBSD (this is not something I have knowledge of or care of).
Something installed from ports, or some commands from the handbook that I ran to enable VirtualBox, Samba or CUPS operation affected the terminal.

Where does gnome-terminal store its profiles? I would need to turn that option off in the config files on my other FreeBSD box where even the 1st copy immediately shuts down.

Edit: 1 min after it worked and I could start several copies of terminal, it is not working anymore. When option to hold the terminal is set to 'hold' it displays the message across the top: 





> The child process exited normally with status 0.


 Does that mean that it's the shell issue instead?

This is actually a workaround, as pressing 'Relaunch' button brings back the shell in a 'half-dead' terminal. What diagnostics can I perform to figure out why shell dies?

EDIT: Can it have anything to do with FUSE? I found that kernel module was missing and loaded fuse, and now I can start 2 terminals. The 3d terminal will still immediately exit its shell, but 2 is different than 1 that I could start before loading fuse module.


----------



## user00 (Apr 2, 2014)

This is insane! Cannot start even a 2nd copy of terminal today. Nothing changed from last night


----------



## user00 (Apr 11, 2014)

Can we try to get to the bottom of it?
The 2nd terminal window should not auto-close, crash, die or quit all by itself for whatever reason.
If it had a legitimate reason to crash, why then is it possible to re-launch shell when the window is set to not close on exit?

Thank you!


----------



## wblock@ (Apr 12, 2014)

Are there any errors reported in /var/log/messages?  What shell is it?  What changes have you made to the shell startup file, like .cshrc or .profile?  Have you changed any localization settings?


----------



## user00 (Apr 12, 2014)

This is the shell with $ prompt, I think it's csh.
This is it for the errors, no new lines are being logged as the 2nd terminal is started, tested with tail.

```
$ cat messages |grep error
Apr 11 22:59:40 l-bsd kernel: error: [drm:pid2258:radeon_cs_ib_chunk] *ERROR* Invalid command stream !
Apr 12 12:09:00 l-bsd dbus[880]: [system] Rejected send message, 2 matched rules; type="method_call", sender=":1.71" (uid=1001 pid=1263 comm="") interface="org.freedesktop.DBus.Properties" member="GetAll" error name="(unset)" requested_reply="0" destination=":1.4" (uid=0 pid=1036 comm="")
```
I never changed .cshrc, it's the same as was installed. The situation started prior to me making any changes to .profile. As of this moment, I changed the path to put /usr/local in front. Nothing changed as regards to starting more than 1 copy of terminal.


```
$ cat .profile 
# $FreeBSD: release/10.0.0/share/skel/dot.profile 199243 2009-11-13 05:54:55Z ed $
#
# .profile - Bourne Shell startup script for login shells
#
# see also sh(1), environ(7).
#

# remove /usr/games if you want
PATH=$HOME/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:; export PATH

# Setting TERM is normally done through /etc/ttys.  Do only override
# if you're sure that you'll never log in via telnet or xterm or a
# serial line.
# TERM=xterm; 	export TERM

BLOCKSIZE=K;	export BLOCKSIZE
EDITOR=vi;   	export EDITOR
PAGER=more;  	export PAGER

# set ENV to a file invoked each time sh is started for interactive use.
ENV=$HOME/.shrc; export ENV

if [ -x /usr/games/fortune ] ; then /usr/games/fortune freebsd-tips ; fi
```


----------



## wblock@ (Apr 12, 2014)

Error messages do not always contain the word "error".  If there were problems logged, it would be at the very end of /var/log/messages.


----------



## user00 (Apr 13, 2014)

What should I look for? When I started the 2 copies of the terminal, tail was running on the messages and no new entries were created.


----------



## wblock@ (Apr 13, 2014)

It's hard to say specifically what to look for, because most of us have never seen this.  A stock install does not do it.  The prime suspects are modifications, things that run in shell startup scripts, or settings that have been copied from other systems that do not work the same way as FreeBSD.

If no error messages are produced, using truss(1) to compare the times when it works (as root) to when it does not (as a normal user) might make the problem obvious.


----------



## user00 (Apr 15, 2014)

Yes, the stock install does do that on my other box. It's a P4 3GHz with 2 GB SDRAM and 200 GB IDE disk. I run 32bit FreeBSD 10 on that box and from get go could only start 1 terminal.


----------



## wblock@ (Apr 15, 2014)

I just tested on another system.  No problems.  This is just using `startx`, with this in .xinitrc:

```
exec /usr/local/bin/startxfce4 --with-ck-launch
```
No login manager.  The non-root user was a member of the wheel group.  Oh, and this is 10-STABLE, amd64.


----------



## user00 (Apr 15, 2014)

Must be the installed packages then. The vanilla install worked fine, then I changed the profile preferences as described above and it started immediately without any actions in between.


----------



## onyxrev (May 27, 2014)

FWIW I found that changing the user's shell to bash solved the problem entirely*.*


----------



## wblock@ (May 27, 2014)

What was the user's shell before the change?


----------



## byuu (May 27, 2014)

I spent a long time trying to research and fix this, but unfortunately failed.

The actual symptom is very sporadic, and prone to leading people to think they have fixed it. Whenever a new terminal is spawned (it doesn't have to be a second terminal), there's a chance the window will close almost immediately. Sometimes it happens almost every time. Sometimes it only happens every 100 times. Sometimes it won't happen for days.

GTK+-based terminals use a GNOME library called libvte. This provides a GTK+ widget for the terminal itself, and also opens a process to the user's shell (fork+exec). libvte then communicates with it over a pipe, which it uses glib to monitor (g_io_add_watch_full), which it calls a reaper. When it detects that the shell has terminated (it is receiving G_IO_HUP), it then kills its own widget. Both gnome-terminal and xfce4-terminal watch to see when the vte widget is destroyed, and will then terminate the terminal processes. Usually, typing `exit` on the terminal does this, so it's normally a good thing to do.

The root of the problem is that the /bin/sh process is exiting normally (exit code 0, EXIT_SUCCESS) for some reason. What makes it so ridiculously insane to debug is that it happens approximately 200ms - 2000ms after libvte has completed initialization. The /bin/sh process starts, prints PS1, and waits a bit, and then boom. It just closes all of a sudden. Your terminal is in the middle of gtk_main_iteration_do when this happens, so you can't place any debug-printf statements inside either xfce4-terminal or libvte to catch what exactly is doing it.

The only way this is going to be fixed properly is for someone to build their own /bin/sh and insert their own debug hooks to determine why it is exiting "normally." I was getting overwhelmed by the very large codebases of xfce4-terminal and libvte already, and didn't want to delve into building debug-hooked versions of system tools that were critical to my OS running at all next, so I had to reluctantly give up. We will likely need a core FreeBSD developer to take interest in this.

This bug never occurs with non-libvte terminals, such as xterm and urxvt. But of course, those are far less "elegant."

What I believe to be the underlying cause of the issue: libvte was written by the GNOME team, which mostly focuses on Linux. There, /bin/sh is actually GNU bash in drag. Whereas FreeBSD has a real sh without all the bash extensions present. I believe that libvte is doing something that bash is fine with, but FreeBSD sh sporadically is not okay with. I suspect the fix will belong in libvte, but given all the GNOME 3 / systemd / Linux-only stuff lately ... I am not sure how receptive they'd be. Then it'd be on FreeBSD to handle whatever weird thing it is they are doing, which might possibly also be an issue. It's a nasty gray-area issue.

What is really bizarre is that I don't actually see any FD writes from libvte into the /bin/sh file descriptor handle at the time it exits. Yet if it were strictly a bug in /bin/sh, it would manifest itself with xterm as well.

The only reliable workaround I have found is the same as @onyxrev's. `sudo pkg install bash && chsh -s /usr/local/bin/bash && logout`
When you log back in to Xorg, your virtual terminals will be using bash as well now, and the problem goes away entirely.

Things I can definitively rule out:

this is not caused by your shell profile (eg `set +o emacs`, etc)
this is not caused by dbus (dbus enables terminal tabs to be dragged between windows)
this is not caused by the video driver
this is not caused by the input section of xorg.conf
this is not caused by a compositor
this happens with multiple versions of libvte
this has existed through several FreeBSD release builds; I've seen people reporting it since FreeBSD 6.x and is still present in 10.0
If you want the relevant code sections for xfce4-terminal and libvte, I posted my research here, with the interesting research on page 2: http://board.byuu.org/viewtopic.php?f=7&t=4601 (warning: crass language, intense frustration contained therein.)

Note: I don't know if this also happens with csh, as I don't use it.


----------

