Bug 55064 - gnome-terminal factory failures
Summary: gnome-terminal factory failures
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: gnome-core   
(Show other bugs)
Version: 7.2
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Havoc Pennington
QA Contact: Aaron Brown
Depends On:
TreeView+ depends on / blocked
Reported: 2001-10-25 00:38 UTC by Joe Harrington
Modified: 2005-10-31 22:00 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-10-25 19:21:01 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Joe Harrington 2001-10-25 00:38:54 UTC
Description of Problem:

Gnome-terminals started with the --use-factory option and not specifying a
class fail, and are replaced by stand-alone windows that do not inherit the
environment or ssh-agent access of either the caller or the program running
in the factory gnome-terminal.

Version-Release number of selected component (if applicable):


How Reproducible:


Steps to Reproduce:

gnome-terminal --start-factory-server --tclass left &
gnome-terminal --use-factory --tclass right &
gnome-terminal --use-factory &

# in each window:
ssh-add -l 

Actual Results:

The process that starts the third window exits, and another takes its
place.  Now job control is gone for that window.
The first 2 windows can connect to the agent, the last can't
The user's environment is not fully propagated into the third window

Expected Results:

All windows should act like the first two.

Additional Information:

Comment 1 Havoc Pennington 2001-10-25 16:59:15 UTC
I'm pretty sure this is what's supposed to happen; if you --use-factory, then 
gnome-terminal simply asks the existing gnome-terminal process to open a new
window and exits, so obviously the new window will not have the environment,
etc. of the shell where you ran the third gnome-terminal. If you want each
gnome-terminal window to be a standalone process, don't use the --use-factory

If I'm misunderstanding the report, please reopen.

Comment 2 Joe Harrington 2001-10-25 19:20:54 UTC
Sorry to reopen, but I do think you misunderstand my point...

1. The program does *both* behaviors.  If it did one or the other
   consistently, you document it and it technically wouldn't be a

2. ...but it would be a gross design error!  Even if dropping the
   environment were deliberate, gnome-terminal would be the very first
   terminal program or shell ever to do so.  You're *supposed* to be
   able to set configuration variables and get them inherited, and
   ssh-agent doesn't work any other way.  However, the new windows get
   started with a gnome function whose name indicates its intention to
   propagate the environment.  It occasionally gets blatted to the
   calling terminal as an error, but it isn't there now and I can't
   make it do it (see below).  *Which* environment (the caller's or
   the factory's) should get inherited could get argued either way.
   I'd say the caller's, and it's quite possible to arrange it that
   way.  In fact, when it succeeds, that's how it does it: the initial
   gt process communicates its environment to the factory and hangs
   around for job control.

But wait, the plot unfortunately thickens.  Even though it was 100%
reproducible before, I can no longer reproduce the behavior.  I have
changed some preferences, including adding a new terminal class, and
everything works as I expect it to now (except window placement with
--geometry, but that's a bug for another day).  I have erased
.gnome/Terminal and tried to get it to happen again with a fresh
config file, but it won't.  So, it's intermittent, and probably has
something to do with the preference settings.  Under at least one
combination, the absence of --tclass in the command line caused the
behavior.  The terminal class is in no way related to whether it
starts in a factory or not, and there is no documentation arguing the
contrary (I refer to the Gnome Terminal User's Guide).

So, unless you can reproduce it, we'll have to leave it at that until
someone discovers the combination of preferences that tickles this
bug.  I'm dropping the priority and severity, since it probably won't
hurt many people.  You can resolve to a worksforme if you want (I
can't do that).


Comment 3 Havoc Pennington 2001-10-25 19:48:37 UTC
OK, certainly it shouldn't be inconsistent. I filed the bug upstream here:

Going to close it on the Red Hat level since I don't expect to fix it in Red Hat
specific patches.

Note You need to log in before you can comment on or make changes to this bug.