GNOME Bugzilla – Bug 98715
loses parent environment variables on startup
Last modified: 2008-09-25 18:54:50 UTC
Hi, http://bugs.debian.org/169368 gnome-terminal loses the environment varibles which are set in the calling process. If one sets an environment variable in his shell and then starts a new gnome-terminal: % export BLA=1 % gnome-terminal The variable BLA will be lost in the new terminal. In practice this causes problems with the ssh-agent that is started from /etc/X11/gdm/Session/Gnome, since the $SSH_* variables don't make it into the gnome-terminal. I am not really sure what the cause for this is, but it has something to do with the way new terminals are startet. A workaround is to start the gnome-terminal with the parameter --disable-factor or setting: 'terminal.c:85:static gboolean terminal_factory_disabled = FALSE; to TRUE.
it's sort of unclear how to fix this (since there's only one g-t process in factory mode, and it can only have one environment). I suppose we could store an environment per-terminal-tab/window, but that probably creates other issues. An in-between road might special-case the forwarding of some specific env variables, just as ssh does.
Adding keywords.
*** Bug 123085 has been marked as a duplicate of this bug. ***
*** Bug 121679 has been marked as a duplicate of this bug. ***
Bug 121697 suggested, at least, documenting this behaviour.
Just came across this with someone on #gnome just now. The hideous workaround fix is to pass: LANG=C gnome-terminal --disable-factory Perhaps it would be possible to pass environ from gnome-terminal to the factory to be used when execve-ing.
Why not just save all environment variables passed on startup? To save memory for unmodified variables, GQuark could be used to intern() the strings.
On Linux at least, it is possible to retrieve environ for another process you own. Without having read any code, I could envision this happening like so. - client sends signal to factory telling it to create a new terminal, it includes its PID; - Factory does the bits and pieces to create a new shell and fork()s process for shell; - child process gets environ for original PID, calls execve with this environ; - shell comes into existance with this environ, client is let terminate Not sure how portable this is, but would require almost zero extra IPC.
Davyd: Looking forward to your implementation (as a we lack an active maintainer).
I might see what I can do after the exams. There are a couple of other things in gnome-terminal that could possibly do with some love. It would be nice to find a new maintainer however.
Created attachment 55138 [details] [review] implementation Environ is transferred with the factory connection. Things to note, - we can't pass a NULL delimiter (the only thing argv can't contain), so we pass environ first with a text delimiter that isn't an environment variable. - this has not been widely tested for leaks or dodginess, but seems to work
Comment on attachment 55138 [details] [review] implementation patch looks plausible to me, not that I am maintaining this thing. :-P
Commited to HEAD.
In Ubuntu we had trouble with the latest release (2.13.0). People could in some cases open only one terminal (reproducibly with --geometry=100x37). After reverting this very patch, everybody was happy again. I'd rather REOPEN this bug and re-review the patch.
Causes hangs.
Ok. Looking at this quickly. The problem with starting new terminals was because you have to firstly shut down the factory (since the factory protocol has now changed). There is however a problem with sending the argv it seems (any argv seems to be a problem). I'll look into it.
*** Bug 324716 has been marked as a duplicate of this bug. ***
*** Bug 324443 has been marked as a duplicate of this bug. ***
Meanwhile, please back the patch out of CVS.
For the reference, I've opened a Fedora bug for reverting this patch, cause it causes a memory corruption (and a hang when glibc is trying to get the stack trace): https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176642
This is not a stable tree, I think cooking a fix to this issue will be more productive than backing it out. I can reproduce the glibc memory corruption message, but have not yet determined where it is taking place. Some help in this matter would be most appreciated.
If you wanna keep it in the tree so someone else could fix it, okay. Alternatively, I've posted a reversal patch to the Fedora bugzilla (or simply patch -R'ing your patch works as well).
*** Bug 325292 has been marked as a duplicate of this bug. ***
I've backed out the patch. Gnome-terminal is unusable with this patch and it is very close to a new release.
*** Bug 325433 has been marked as a duplicate of this bug. ***
Marking depending on bug 399209 so we remember to fix this when we switch the single-instance protocol.
*** Bug 497044 has been marked as a duplicate of this bug. ***
This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.