Bug 1806050 - gnome-terminal-nautilus opens different environment when using Right Click 'Open Terminal' in Nautilus
Summary: gnome-terminal-nautilus opens different environment when using Right Click 'O...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: gnome-terminal
Version: 8.4
Hardware: x86_64
OS: Linux
unspecified
low
Target Milestone: beta
: 8.6
Assignee: David King
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-02-21 21:30 UTC by Jonathan Billings
Modified: 2021-08-21 07:26 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-08-21 07:26:57 UTC
Type: Bug
Target Upstream Version:


Attachments (Terms of Use)

Description Jonathan Billings 2020-02-21 21:30:56 UTC
Description of problem:
We have gnome-terminal-nautilus and environment-modules installed on our systems.  We discovered that if you open a Terminal by right-clicking on a directory or the background of an open nautilus window (where the files are), and select "Open Terminal", the 'module' function defined in /etc/profile.d/modules.sh is not defined.  If you open a Terminal in any other way, the module function is defined.

Version-Release number of selected component (if applicable):
gnome-terminal-nautilus-3.28.2-2.el7.x86_64
environment-modules-3.2.10-10.el7.x86_64


How reproducible:
Always

Steps to Reproduce:
1. Install gnome-terminal-nautilus and environment-modules
2. Log into a GNOME desktop system
3. Open up nautilus
4. Right-click on a directory or the open nautilus window in the file browser
5. Select "Open Terminal"
6. Enter 'module'

Actual results:
bash-4.2$ module
bash: module: command not found


Expected results:
bash-4.2$ module
cmdModule.c(166):ERROR:11: Usage is 'module command  [arguments ...] '

  Modules Release 3.2.10 2012-12-21 (Copyright GNU GPL v2 1991):

  Usage: module [ switches ] [ subcommand ] [subcommand-args ]

Switches:
	-H|--help		this usage info
	-V|--version		modules version & configuration options
	-f|--force		force active dependency resolution


Additional info:

Comment 2 Jonathan Billings 2020-02-21 21:34:28 UTC
One more thing to add, our users use a network homedir which have no ~/.bashrc or ~/.bash_profile.  To reproduce this, you have to remove the line that has '. /etc/bashrc' from your ~/.bashrc, or remove the file entirely.

Our solution is to have the user copy over /etc/skel/.bashrc to their .bashrc.

It seems that shells started by "Open Terminal" in nautilus open a different environment than any other method of opening a Terminal.

Comment 3 Debarshi Ray 2020-05-29 16:56:23 UTC
> One more thing to add, our users use a network homedir which have no
> ~/.bashrc or ~/.bash_profile.  To reproduce this, you have to remove the
> line that has '. /etc/bashrc' from your ~/.bashrc, or remove the file
> entirely.
> 
> Our solution is to have the user copy over /etc/skel/.bashrc to their
> .bashrc.

I am a bit confused. The template at /etc/skel/.bashrc also includes /etc/bashrc. Would it be possible to have a look at a sample ~/.bashrc and ~/.bash_profile?

The drop-in scripts at /etc/profile.d are pulled in by either /etc/profile or /etc/bashrc, depending on whether the shell is a login shell or not. So, it's worth checking if the shell started from Nautilus and the shell otherwise are login shells or not. Here's one way to do that:
  $ shopt -q login_shell && echo 'Login shell' || echo 'Not login shell'

Comment 4 Jonathan Billings 2020-05-29 17:17:39 UTC
Our users start with no .bashrc or .bash_profile.  This behaviour only happens if you don't have a .bashrc or have a .bashrc that doesn't source /etc/bashrc.

Comment 5 Debarshi Ray 2020-06-01 15:14:08 UTC
Ok, I can reproduce this.

When a new GNOME Terminal is obtained via the GNOME Shell UI, the new process is forked from the gnome-shell process, which has the module() function defined in its environment. This definition is then inherited by the new terminal.

However, when a new terminal is created from inside a Nautilus window, the new process is forked from the user's instance of the dbus-daemon process (actually the nautilus process, which was forked from the user's dbus-daemon). The dbus-daemon process doesn't have the module() definition and hence it's also missing from the new terminal.

You'll notice that the module() function is also defined if a new terminal is opened from the desktop (when desktop icons are enabled). Even though the desktop icons are provided by an instance of Nautilus, that particular nautilus process is forked from gnome-shell, not the user's dbus-daemon. Hence the module() function is defined and inherited by the new terminal.

Comment 6 Ray Strode [halfline] 2020-06-03 17:57:01 UTC
Hi,

So the session is normally started through a few wrappers, something like:

dbus-run-session -- /etc/X11/xinit/Xsession "gnome-session"

dbus-run-session ensures a session bus is started, and /etc/X11/Xsession makes a call that ensures the session is run "through" a login shell.  Something like:

→       →       exec /bin/sh -c "exec -l $SHELL -c \"$1\""

(where "$1" is interpreted to mean "gnome-session")

Note the exec -l $SHELL in the above command.  This tells the shell (pobably bash, but it depends on what the user has configured in /etc/passwd) to run
a login shell.  When the login shell is run /etc/profile.d is sourced.  But notice, this is after dbus-run-session runs and after the bus is started!

Later if the user does something that leads to a program getting started from the dbus-daemon, that process will be running under dbus-daemon's environment,
not the environment of the login shell.  Normally, this isn't that big of a deal, because gnome-session will actually forward the environment to dbus-daemon
at login time. But it can't really forward functions, just environment variables.  Again, this isn't usually a problem because ~/.bashrc sources /etc/profile.d
so any functions defined there get picked up anyway.

Changing dbus-daemon to get run within a login shell is risky. He would likely cause unintentional breakage.

Two potential workarounds:

1) instruct users to put [ -e /etc/bashrc ] && . /etc/bashrc in ~/.bashrc just as we do for the "stock" ~/.bashrc
2) there's a setting in gnome-terminal to make it always run a login shell itself, for its shell.  just tick that box in your site local configuration, or ask
users to set it the setting themselves.
3) maybe just install a script called /usr/local/bin/module that does:

#!/bin/bash

if ! declare -F module >& /dev/null; then
  [ -e /etc/profile.d/modules.sh ] || exit 1

  . /etc/profile.d/modules.sh

  declare -F module >& /dev/null || exit 1
fi

module "$@"

Comment 7 Christian Persch 2020-06-03 20:36:15 UTC
There is recent gnome-terminal upstream report [https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/253] where it was found that some important env variables [e.g. ssh-agent ones] are missing from the systemd --user activation environment but are present in the desktop's (gnome-shell, etc)'s environment. Is that related to/the same as this problem here?

Comment 8 Ray Strode [halfline] 2020-06-08 14:39:50 UTC
chpe, probably different.  this is only about bash functions not environment variables.

Comment 10 Debarshi Ray 2021-04-16 20:06:37 UTC
RHEL 7 is in Maintenance Support 2 phase. We need to be very selective about the bugs we address, in order to keep the changes minimal.

Therefore, I am going to move it to RHEL 8, in the hope that we can fix it there.

Comment 13 RHEL Program Management 2021-08-21 07:26:57 UTC
After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.


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