[solved] Wayland: Path has double entries for the jre and perl?

IrvineHimself · 2019-06-25 15:05:23

I noticed my ${PATH} has double entries for the java run time environment and perl packages:

*$ echo ${PATH}
/usr/local/bin/FjSymlinks:/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl
*$

Is this a bug I should report, or is it something I have done?

For reference:
A couple of weeks ago, long before I noticed the jre and perl double entries, I noticed a similar problem when I added FjSymlinks to the path in my .bash_profile. As it turned out, it was an artefact caused by the .bash_profile being called once at log-on and again when I launched the gnome-terminal. I solved the problem with FjSymlinks by adding it to the path in .pam_environment.

I’m running Wayland, and my .bash_profile is:

#
# ~/.bash_profile
#

[[ -f ~/.bashrc ]] && . ~/.bashrc

# Everything below was added by me :)

if [[ -z $DISPLAY ]] && [[ $(tty) = /dev/tty1 ]] && [[ $XDG_SESSION_TYPE = tty ]]; then
  # Launch my text based throbber
  EtcIssueThrobber &
fi

if [[ -z $DISPLAY ]] && [[ $(tty) = /dev/tty1 ]] && [[ $XDG_SESSION_TYPE = tty ]]; then
  # Launch gnome-shell (see https://wiki.archlinux.org/index.php/GNOME#Wayland_sessions)
  # Redirected stndout and stnderror so as not to interfere with throbber
  QT_QPA_PLATFORM=wayland XDG_SESSION_TYPE=wayland exec dbus-run-session gnome-session > /dev/null 2>&1
fi


# Import environment into systemd/user. (In wayland, setting the correct environmental variables for
# systemd/user is not quite as transparent as it was under the xorg-server.)
# see https://wiki.archlinux.org/index.php/Systemd/User#Environment_variables
systemctl --user import-environment

my .pam_environment. is:

# I believe this is functionally equivalent to /etc/environment

# For a general discussion of environment variables
# see https://wiki.archlinux.org/index.php/.pam_environment#Per_user


# Added by me to fix large Vlc icons
# see https://forum.videolan.org/viewtopic.php?t=144265
QT_AUTO_SCREEN_SCALE_FACTOR=0

# Added by me to get qtc5t tool working
QT_QPA_PLATFORMTHEME=qt5ct

# Added by me to set FjSymlinks in path
# see https://wiki.archlinux.org/index.php/.pam_environment#Per_user
PATH=/usr/local/bin/FjSymlinks

and my .bashrc is:

#
# ~/.bashrc
#

# If not running interactively, don't do anything
[[ $- != *i* ]] && return

alias ls='ls --color=auto'
#PS1='[\u@\h \W]\$ '

# Customise bash prompt. Note: escape sequences for PS1 need special handling
# with extra "[]", else the terminal can get confused about the cursor position :)
# (For 'sudo -i' prompt see if/then statement appended to /etc/bash.bashrc)
PS1='\[\e[1;34;1m\]*\[\e[1;32;1m\]$ \[\e[0m\]'

# Customise default terminal title (For 'sudo -i' title, see if/then statement appended to /etc/bash.bashrc)
PROMPT_COMMAND='echo -ne "\033]0;${PWD}\007"'

# Added by me to give output some colour
alias diff='diff --color=auto'
alias grep='grep --color=auto'
alias ip='grc ip'
alias ps='grc ps'
alias gcc='grc gcc'
alias ping='grc ping'

# Carries the  aliases over to the root account when using sudo
# see https://wiki.archlinux.org/index.php/Sudo
alias sudo='sudo '

As it is, unless you try to call something that is not in the ${PATH}, it has absolutely zero affect, but still … it could indicate something more fundemental (?)

I would be grateful to hear your thoughts
Irvine

Last edited by IrvineHimself (2019-06-28 05:46:23)

seth · 2019-06-25 19:36:28

Probably caused by sth. in /etc/profile.d and likely either a java or perl distributed script

IrvineHimself · 2019-06-26 05:12:53

Okay, I have been looking through the wiki for places where the double entries might be originating.

Firstly, as per @seth's suggestinon, (thankyou,) I listed the contents of /etc/profile.d/

*$ ls -AFl
total 60
-rw-r--r-- 1 root root  545 Apr 22 06:56 freetype2.sh
-rw-r--r-- 1 root root 1107 Jan 10 15:00 gawk.csh
-rw-r--r-- 1 root root  757 Jan 10 15:00 gawk.sh
-rwxr-xr-x 1 root root  105 Sep 29  2018 gpm.sh*
-rw-r--r-- 1 root root 1373 Jun 11  2018 grc.bashrc
-rw-r--r-- 1 root root  207 Sep 22  2017 jre.csh
-rw-r--r-- 1 root root  205 Sep 22  2017 jre.sh
-rw-r--r-- 1 root root  222 May 22 12:56 libreoffice-fresh.csh
-rw-r--r-- 1 root root  222 Jun 16 11:52 libreoffice-fresh.sh
-rw-r--r-- 1 root root  766 May 23 15:18 locale.sh
-rwxr-xr-x 1 root root   50 Jun  4  2018 mozilla-common.csh*
-rwxr-xr-x 1 root root   50 Jun  4  2018 mozilla-common.sh*
-rw-r--r-- 1 root root  699 Jun 18 18:57 perlbin.csh
-rw-r--r-- 1 root root  668 Jun 18 18:57 perlbin.sh
-rw-r--r-- 1 root root 1945 May  6 22:22 vte.sh
*$

Grepping for something that can change the ${PATH}

*$ grep -l ' PATH=' *
jre.sh
perlbin.sh
*$

Which is about what I would expect. I haven’ t touched these files, but for completeness

/etc/profile.d/jre.sh

*$ cat jre.sh
# Do not change this unless you want to completely by-pass Arch Linux' way
# of handling Java versions and vendors. Instead, please use script `archlinux-java`
export PATH=${PATH}:/usr/lib/jvm/default/bin
*$

/etc/profile.d/perlbin.sh

*$ cat perlbin.sh
# Set path to perl scriptdirs if they exist
# https://wiki.archlinux.org/index.php/Perl_Policy#Binaries_and_scripts
# Added /usr/bin/*_perl dirs for scripts
# Remove /usr/lib/perl5/*_perl/bin in next release

[ -d /usr/bin/site_perl ] && PATH=$PATH:/usr/bin/site_perl
[ -d /usr/lib/perl5/site_perl/bin ] && PATH=$PATH:/usr/lib/perl5/site_perl/bin

[ -d /usr/bin/vendor_perl ] && PATH=$PATH:/usr/bin/vendor_perl
[ -d /usr/lib/perl5/vendor_perl/bin ] && PATH=$PATH:/usr/lib/perl5/vendor_perl/bin

[ -d /usr/bin/core_perl ] && PATH=$PATH:/usr/bin/core_perl

export PATH

# If you have modules in non-standard directories you can add them here.
#export PERLLIB=dir1:dir2

*$

From reading the Wiki here and here, the other likely culprits I can think of are :

/etc/environment

*$ cat environment
#
# This file is parsed by pam_env module
#
# Syntax: simple "KEY=VAL" pairs on separate lines
#

*$

/etc/profile

*$ cat profile
# /etc/profile

# Set our umask
umask 022

# Append our default paths
appendpath () {
    case ":$PATH:" in
        *:"$1":*)
            ;;
        *)
            PATH="${PATH:+$PATH:}$1"
    esac
}

appendpath '/usr/local/sbin'
appendpath '/usr/local/bin'
appendpath '/usr/bin'
unset appendpath

export PATH

# Load profiles from /etc/profile.d
if test -d /etc/profile.d/; then
	for profile in /etc/profile.d/*.sh; do
		test -r "$profile" && . "$profile"
	done
	unset profile
fi

# Source global bash config
if test "$PS1" && test "$BASH" && test -z ${POSIXLY_CORRECT+x} && test -r /etc/bash.bashrc; then
	. /etc/bash.bashrc
fi

# Termcap is outdated, old, and crusty, kill it.
unset TERMCAP

# Man is much better than us at figuring this out
unset MANPATH
*$

/etc/bash.bashrc

*$ cat bash.bashrc
#
# /etc/bash.bashrc
#

# If not running interactively, don't do anything
[[ $- != *i* ]] && return

[[ $DISPLAY ]] && shopt -s checkwinsize

PS1='[\u@\h \W]\$ '

case ${TERM} in
  xterm*|rxvt*|Eterm|aterm|kterm|gnome*)
    PROMPT_COMMAND=${PROMPT_COMMAND:+$PROMPT_COMMAND; }'printf "\033]0;%s@%s:%s\007" "${USER}" "${HOSTNAME%%.*}" "${PWD/#$HOME/\~}"'

    ;;
  screen*)
    PROMPT_COMMAND=${PROMPT_COMMAND:+$PROMPT_COMMAND; }'printf "\033_%s@%s:%s\033\\" "${USER}" "${HOSTNAME%%.*}" "${PWD/#$HOME/\~}"'
    ;;
esac

[ -r /usr/share/bash-completion/bash_completion   ] && . /usr/share/bash-completion/bash_completion

# Appended by me to set root prompt and terminal title  (see my $HOME/.bashrc)
if [ $(id -u) -eq 0 ]; then # I'm root, make the prompt red
    PS1='\[\e[1;34;1m\]*\[\e[1;31;1m\]# \[\e[0m\]'
    PROMPT_COMMAND='echo -ne "\033]0;root:  ${PWD}\007"'
fi
*$

I seem to recall that /etc/environment is mirrored somewhere as a stub, but I can’t recall exactly where? If someone can remind where it is mirrored, I will also check that location, or anywhere else the double entries might be creeping in.

Interestingly, I can't seem to reproduce the original double entries I observed for FjSymlinks using my .bash_profile to set the ${PATH} ???

Irvine

seth · 2019-06-26 07:22:41

Nope.
Because of the gnome-terminal condition I'd check whether this happens for a new user and in an xterm (or just the console)

IrvineHimself · 2019-06-26 08:59:47

Okay, that's interesting. Commenting out the bit that launches the gnome-shell, in the console I ran echo $PATH > ConsolePath and got:

*$ cat ConsolePath
/usr/local/bin/FjSymlinks:/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl
*$

For reference, my .bash_profile for the test was:

#
# ~/.bash_profile
#

[[ -f ~/.bashrc ]] && . ~/.bashrc

# Everything below was added by me :)

if [[ -z $DISPLAY ]] && [[ $(tty) = /dev/tty1 ]] && [[ $XDG_SESSION_TYPE = tty ]]; then
  # Launch my text based throbber
  EtcIssueThrobber &
fi

#if [[ -z $DISPLAY ]] && [[ $(tty) = /dev/tty1 ]] && [[ $XDG_SESSION_TYPE = tty ]]; then
#  # Launch gnome-shell (see https://wiki.archlinux.org/index.php/GNOME#Wayland_sessions)
#  # Redirected stndout and stnderror so as not to interfere with throbber
#  QT_QPA_PLATFORM=wayland XDG_SESSION_TYPE=wayland exec dbus-run-session gnome-session > /dev/null 2>&1
#fi

# Import environment into systemd/user. (In wayland, setting the correct enviromental variables for
# systemd/user is not quite as transparent as it was under the xorg-server.)
# see https://wiki.archlinux.org/index.php/Systemd/User#Environment_variables
systemctl --user import-environment

It looks like it is definitely something to do with the gnome-shell?
Irvine
Edit, I have a few things to take care of, but after lunch I will create a new user for gnome, and see if the problem persists

Last edited by IrvineHimself (2019-06-26 09:01:58)

V1del · 2019-06-26 09:02:31

What happens if you omit the dbus-run-session and just start gnome-session ? You should already have a DBUS session after succesful console log on, there should be no need to start another.

But definitely try the other user first, maybe you've simply got something in the user's session autostart.

Last edited by V1del (2019-06-26 09:09:29)

frostschutz · 2019-06-26 09:24:47

it doubles everytime you spawn a new login shell when that path is already set

and it just so happens when I start fluxbox from lightdm, it's already set and then every terminal sets it again, so it's doubled

if you run bash --login and then echo $PATH it's tripled

I think other distros set a static path in /etc/profile instead of keeping original path and just trying to fix it with appendpath. that way whatever the path was previously, profile gives you a clean static path.

with appendpath logic, everything else has to use appendpath too (check it's not already in PATH before adding to PATH) or you'll see double path entries in places

Last edited by frostschutz (2019-06-26 09:26:45)

seth · 2019-06-26 10:33:09

@frostschutz, do you use gnome-terminal as well? (Or why would your VTE run a login shell?)

frostschutz · 2019-06-26 11:37:04

I use urxvt.

I tried to write a small script that traces PATH history upwards in the process tree chain:

#!/bin/bash

/bin/sleep 10 &
pid=$!

while [ $pid != 0 ]
do
    echo "$pid" \
         "[ $(tr '\0' ' ' < /proc/$pid/cmdline)]:"
    echo "---> $(grep --null-data '^PATH=' /proc/$pid/environ | xargs -0)"
    read x x x pid x < /proc/$pid/stat
done

# ./pathtree.sh 
4566 [ /bin/sleep 10 ]:
---> PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl
4565 [ /bin/bash ./pathtree.sh ]:
---> PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl
4564 [ bash ]:
---> PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl
4563 [ su ]:
---> PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl
4561 [ bash ]:
---> PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl
4560 [ urxvt ]:
---> PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl
2085 [ /usr/bin/fluxbox ]:
---> PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl
2076 [ /bin/sh /etc/lightdm/Xsession gnome-session-remmina ]:
---> PATH=/usr/local/bin:/usr/bin:/bin
2063 [ lightdm --session-child 14 21 ]:
---> PATH=/usr/local/sbin:/usr/local/bin:/usr/bin
2010 [ /usr/bin/lightdm ]:
---> PATH=/usr/local/sbin:/usr/local/bin:/usr/bin
1 [ /sbin/init ]:
--->

The PATH is obtained from /proc/pid/environ which is the PATH the process was started with (not the PATH the process itself changed to). So if a process is started with an odd path, the parent process is the culprit.

So init was started with empty path.

init started lightdm with PATH=/usr/local/sbin:/usr/local/bin:/usr/bin

lightdm started /bin/sh /etc/lightdm/Xsession

/bin/sh started fluxbox with PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl

fluxbox started urxvt, urxvt started bash, and bash started su with PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl

so there are two shells in the chain (the shell script that starts the Xsession, and the bash inside the terminal) and you have double elements in the PATH

When I use 'su -' instead of just 'su' to get the root shell:

# ./pathtree.sh 
4654 [ /bin/sleep 10 ]:
---> PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl
4653 [ /bin/bash ./pathtree.sh ]:
---> PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl
4651 [ -bash ]:
---> PATH=/usr/local/sbin:/usr/local/bin:/usr/bin
4650 [ su - ]:
---> PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl
4561 [ bash ]:
---> PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl
4560 [ urxvt ]:
---> PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl
2085 [ /usr/bin/fluxbox ]:
---> PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl
2076 [ /bin/sh /etc/lightdm/Xsession gnome-session-remmina ]:
---> PATH=/usr/local/bin:/usr/bin:/bin
2063 [ lightdm --session-child 14 21 ]:
---> PATH=/usr/local/sbin:/usr/local/bin:/usr/bin
2010 [ /usr/bin/lightdm ]:
---> PATH=/usr/local/sbin:/usr/local/bin:/usr/bin
1 [ /sbin/init ]:
--->

su - gets started with PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl

-bash then gets started with PATH=/usr/local/sbin:/usr/local/bin:/usr/bin

the pathtree.sh shellscript itself then is back to PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl (because bash started by su - read the profile file, no doubt)

now, urxvt has a loginShell setting. according to manpage it defaults to on. I guess I could set it to off... but it seems like the wrong fix

       loginShell: boolean
           True: start as a login shell by prepending a `-' to argv[0] of the
           shell; option -ls. False: start as a normal sub-shell [default];
           option +ls.

but it's odd since su - starts -bash but urxvt starts bash without - so not sure what is going on, well, it could be exec

Last edited by frostschutz (2019-06-26 11:39:39)

IrvineHimself · 2019-06-26 12:44:27

frostschutz wrote:

... if you run bash --login and then echo $PATH it's tripled ...

I confirmed this with the test below, not that I doubted you. I just think the more information we have, the better.

*$ echo $PATH
/usr/local/bin/FjSymlinks:/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl
*$ bash --login
*$ echo $PATH
/usr/local/bin/FjSymlinks:/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl
*$ sudo -i
[sudo] password for stupidme:
*# echo $PATH
/usr/local/bin/FjSymlinks:/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl
*# exit
logout
*$ echo $PATH
/usr/local/bin/FjSymlinks:/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl
*$

This fits in with what I observed about FjSymlinks being doubled and how it appeared to be caused by the gnome-terminal re-running my .bash_profile. However, I am not sure why I couldn't reproduce that doubling earlier this morning?

Irvine

seth · 2019-06-26 13:17:30

su - starts -bash but urxvt starts bash without - so not sure what is going on

according to manpage it defaults to on

loginShell: boolean
True: start as a login shell by prepending a `-' to argv[0] of the
shell; option -ls. False: start as a normal sub-shell [default];
option +ls.

It defaults to a regular shell (because that's sane behavior) so that is not causing the login shell and/or profile reading - sure you didn't source some *profile in some *rc?
What happens if you just run "bash" out of a running bash?

IrvineHimself · 2019-06-26 13:45:43

seth wrote:

... What happens if you just run "bash" out of a running bash?

*$ echo $PATH
/usr/local/bin/FjSymlinks:/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl
*$ bash
*$ echo $PATH
/usr/local/bin/FjSymlinks:/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl
*$

seth wrote:

...sure you didn't source some *profile in some *rc? ...

I'm not sure if this proves the point one way or another, but I just created a completely new user:

useradd -m -s /bin/bash testuserbash
passwd testuserbash

The only edit I made was to give him/her the following .bash_profile

#
# ~/.bash_profile
#

[[ -f ~/.bashrc ]] && . ~/.bashrc

if [[ -z $DISPLAY ]] && [[ $(tty) = /dev/tty1 ]] && [[ $XDG_SESSION_TYPE = tty ]]; then
  QT_QPA_PLATFORM=wayland XDG_SESSION_TYPE=wayland exec dbus-run-session gnome-session
fi

I was still getting the double entries:

*# cat /home/testuserbash/TestUserBashPath
/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl
*#

I notice that in /etc/shells. I have the following

*$ cat /etc/shells
# Pathnames of valid login shells.
# See shells(5) for details.

/bin/sh
/bin/bash
/usr/bin/git-shell
*$

If you think it would help, I could try creating users with /bin/sh and /usr/bin/git-shell

Irvine

seth · 2019-06-26 13:52:42

Sorry, I should have addressed frostschutz, because I don't see urxvt running a login shell for him.
What you could do is to try the behavior on an xterm (and a gnome X11 session) to rule out gnome-terminal simply running a login shell (by default?)

frostschutz · 2019-06-26 14:11:41

OK, it looks like I had a "source /etc/profile" in my .bashrc. (User bashrc, not Root bashrc, hence nothing happened when su root)

I made an attempt at cleaning up the PATH variable anyway: (probably not worth it - at your own risk)

/etc/profile.d/zzz_path_fixer_upper.sh ( zzz so it will execute last )

#
# PATH Fixer Upper
#
# - make sure default paths are first (retain order otherwise)
# - replace path aliases with real path names
# - remove duplicate and nonexisting paths
#

FixerTodo="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:$PATH"
FixerDone=""

# fix our paths - adapted from /etc/profile :: appendpath()
FixerUpperPath() {
    [ -e "$1" ] && set -- "$(realpath "$1"/. 2> /dev/null)" || return
    case "::$FixerDone:" in
        *:"$1":*)
            ;;
        *)
            FixerDone="${FixerDone:+$FixerDone:}$1"
    esac
}

FixerTodo="$FixerTodo:"
while [ "$FixerTodo" ]
do
    FixerUpperPath "${FixerTodo%%:*}"
    FixerTodo="${FixerTodo#*:}"
done

PATH="$FixerDone"
export PATH

unset FixerTodo FixerDone FixerUpperPath

Last edited by frostschutz (2019-06-26 14:27:26)

schard · 2019-06-26 14:59:57

Those are the culprits:

$ grep -r "setenv PATH" /etc/profile.d/
/etc/profile.d/android-sdk.csh:setenv PATH ${PATH}:${ANDROID_HOME}/tools:${ANDROID_HOME}/tools/bin
/etc/profile.d/perlbin.csh:[ -d /usr/bin/site_perl ] && setenv PATH ${PATH}:/usr/bin/site_perl
/etc/profile.d/perlbin.csh:[ -d /usr/lib/perl5/site_perl/bin ] && setenv PATH ${PATH}:/usr/lib/perl5/site_perl/bin
/etc/profile.d/perlbin.csh:[ -d /usr/bin/vendor_perl ] && setenv PATH ${PATH}:/usr/bin/vendor_perl
/etc/profile.d/perlbin.csh:[ -d /usr/lib/perl5/vendor_perl/bin ] && setenv PATH ${PATH}:/usr/lib/perl5/vendor_perl/bin
/etc/profile.d/perlbin.csh:[ -d /usr/bin/core_perl ] && setenv PATH ${PATH}:/usr/bin/core_perl
/etc/profile.d/android-emulator.csh:setenv PATH "${PATH}:${ANDROID_HOME}/emulator"
/etc/profile.d/jre.csh:setenv PATH "${PATH}:/usr/lib/jvm/default/bin"

They just stupidly append their paths each time they are invoked, which is done by /etc/profile.
They should be using appendpath() from /etc/profile, but which is unset before their invocation.

Last edited by schard (2019-06-26 15:01:37)

seth · 2019-06-26 15:11:01

They won't be able to depend on appendpath() anyway since the contents of /etc/profile are not guaranteed (though one should not edit it) - testing PATH before altering it isn't that hard, though.

However the more interesting question atm. is why Irvine / gnome-terminal runs login shells (by default?) since in a "normal" context where you run the login shell on a clean environment and subsequent shell won't source /etc/profile, this would not matter.

CarbonChauvinist · 2019-06-26 15:15:29

@seth this might just be noise, disregard if so, but maybe it has to do with what he described in this post quoted below:

After an afternoon and evening of experimentation with the solution outlined above, I found the best solution was to add the following to my .bash_profile immediately after the section that launches my DE. (in my case, a minimal gnome shell)
# Import environment into systemd/user. (In wayland, setting the correct environmental variables for
# systemd/user is not quite as transparent as it was under the xorg-server.)
# see https://wiki.archlinux.org/index.php/Sy … _variables
systemctl --user import-environment

IrvineHimself · 2019-06-26 15:44:07

CarbonChauvinist wrote:

@seth this might just be noise, disregard if so, ...

No, as I pointed out in post #5, above, when I successfully tested the $PATH from the virtual console, I left that line in my .bash_profile untouched. ie, I only edited out the bit that launched the gnome-shell. This also applies to the successful test I detail below where I run a gnome-classic session.

V1del wrote:

What happens if you omit the dbus-run-session and just start gnome-session ? ...

I tried launching a gnome session from console without invoking dbus with the following,

*$ QT_QPA_PLATFORM=wayland 
*$ XDG_SESSION_TYPE=wayland 
*$ gnome-session

It didn’t make any difference.

seth wrote:

... What you could do is to try the behavior on an xterm (and a gnome X11 session) to rule out gnome-terminal simply running a login shell (by default?)

After installing xterm, xorg-server and xinit

Firstly, running an xterm in pure(ish) wayland environment, the $PATH variable still had double entries:

/usr/local/bin/FjSymlinks:/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl

Then, after creating the following .xinitrc

export XDG_CURRENT_DESKTOP=GNOME-Classic:GNOME
export GNOME_SHELL_SESSION_MODE=classic
exec gnome-session --session=gnome-classic

I used startx to launch a gnome classic session from the console, this worked. Meaning there were no double entries:

/usr/local/bin/FjSymlinks:/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl

I know it was extremely unlikely, but just to be sure, I rechecked that I was still getting double entries under Wayland with the xorg-server installed. This was affirmative.

Evidently, it is something to do with the gnome-shell under Wayland.

Irvine

seth · 2019-06-26 15:48:54

How does weston-terminal behave (on wayland, obviously)?

IrvineHimself · 2019-06-26 16:33:45

Okay, I created a .desktop launcher in $HOME/.local/share/applications/ to ensure it wasn't inheriting anything from the gnome-terminal

/usr/local/bin/FjSymlinks:/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl

Irvine

seth · 2019-06-26 19:33:24

Last best guess, what if you put "exec dbus-run-session startx" into your bash_profile?

IrvineHimself · 2019-06-27 04:50:51

I assume you meant a gnome-classic session with xorg-server running

With the following bash profile:

#
# ~/.bash_profile
#

[[ -f ~/.bashrc ]] && . ~/.bashrc

# Everything below was added by me :)

if [[ -z $DISPLAY ]] && [[ $(tty) = /dev/tty1 ]] && [[ $XDG_SESSION_TYPE = tty ]]; then
  # Launch my text based throbber
  EtcIssueThrobber &
fi

#if [[ -z $DISPLAY ]] && [[ $(tty) = /dev/tty1 ]] && [[ $XDG_SESSION_TYPE = tty ]]; then
#  # Launch gnome-shell (see https://wiki.archlinux.org/index.php/GNOME#Wayland_sessions)
#  # Redirected stndout and stnderror so as not to interfere with throbber
#  # QT_QPA_PLATFORM=wayland XDG_SESSION_TYPE=wayland exec dbus-run-session gnome-session > /dev/null 2>&1
#fi

if [[ -z $DISPLAY ]] && [[ $(tty) = /dev/tty1 ]] && [[ $XDG_SESSION_TYPE = tty ]]; then
  exec dbus-run-session startx
fi

# Import environment into systemd/user. (In wayland, setting the correct environmental variables for
# systemd/user is not quite as transparent as it was under the xorg-server.)
# see https://wiki.archlinux.org/index.php/Systemd/User#Environment_variables
systemctl --user import-environment

The successful result is exactly the same as starting gnome-classic with just a plain startx, ie, it had no negative effect:

*$ echo $PATH
/usr/local/bin/FjSymlinks:/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl
*$

Feel free to call me stupid, but just in case you meant running exec dbus-run-session startx before starting Wayland, I tried this also. For reasons outlined below, (that have absolutely nothing to do with the problem in hand,) I’m glad I did this.

Anyway, (after renaming .xinitrc,) in the console, I ran exec dbus-run-session, which brought me back to my log-on prompt. From there, (after logging in again,) I ran:

*$ startx
*$ QT_QPA_PLATFORM=wayland
*$ XDG_SESSION_TYPE=wayland
*$ gnome-session

Once in the shell, I ran:

*$ echo $PATH
/usr/local/bin/FjSymlinks:/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl
*$ ps -A | grep X
 1064 tty1     00:00:08 Xwayland
*$

Unsurprisingly, Xwayland evidently replaced the X session started by startx

To get back to the exec dbus issue. I edited my .bash_profile to remove the exec dbus-run-session entry, rebooted into a gnome-wayland session, and ran

*$ ps -aux | grep dbus
dbus       831  0.0  0.0  11412  4800 ?        Ss   04:50   0:00 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only
stupidme   936  0.0  0.0  11072  4672 ?        Ss   04:50   0:00 /usr/bin/dbus-daemon --session --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only
stupidme   963  0.0  0.0  10580  3984 ?        S    04:50   0:00 /usr/bin/dbus-daemon --config-file=/usr/share/defaults/at-spi2/accessibility.conf --nofork --print-address 3
stupidme  2413  0.0  0.0   6268  2236 pts/0    S+   05:15   0:00 grep --color=auto dbus
*$

So, while exec dbus-run-session has no effect on the problem in hand, this seems to prove that starting a new dbus-session is superfluous to starting a gnome-wayland session from either a .bash_profile or the console. As a result, I suggest the wiki entry for manually starting gnome-wayland should be corrected.

Irvine

seth · 2019-06-27 05:34:14

I meant what I said (and you did in your first approach ;-)
So this seems exclusive to gnome/wayland (you could check the environment of gnome-shell,

tr '\0' '\n' < /proc/`pidof gnome-shell`/environ

Is gnome-session a script? (As you might have figured: not using gnome here)

V1del already pointed out the superfluous dbus-run-session, https://bbs.archlinux.org/viewtopic.php … 6#p1851706 - and somebody started a talk on this a year ago: https://wiki.archlinux.org/index.php/Ta … nd_session

IrvineHimself · 2019-06-27 10:01:45

Okay, I had to run it as root, which we established above adds another set of entries. So, for comparison, I also echoed the $PATH

*$ sudo tr '\0' '\n' < /proc/`pidof gnome-shell`/environ
bash: /proc/`pidof gnome-shell`/environ: Permission denied
*$ sudo -i
[sudo] password for stupidme: 
*# tr '\0' '\n' < /proc/`pidof gnome-shell`/environ
SHELL=/bin/bash
XDG_SEAT=seat0
PWD=/home/stupidme
LOGNAME=stupidme
QT_QPA_PLATFORMTHEME=qt5ct
XDG_SESSION_TYPE=wayland
HOME=/home/stupidme
LANG=en_GB.UTF-8
INVOCATION_ID=4bf223d792cd4a4c93c70759813f771b
QT_QPA_PLATFORM=wayland
XDG_SESSION_CLASS=user
TERM=linux
USER=stupidme
SHLVL=1
XDG_VTNR=1
XDG_SESSION_ID=1
MOZ_PLUGIN_PATH=/usr/lib/mozilla/plugins
XDG_RUNTIME_DIR=/run/user/1000
QT_AUTO_SCREEN_SCALE_FACTOR=0
JOURNAL_STREAM=9:20678
PATH=/usr/local/bin/FjSymlinks:/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
MAIL=/var/spool/mail/stupidme
XDG_CURRENT_DESKTOP=GNOME
XDG_MENU_PREFIX=gnome-
SESSION_MANAGER=local/mine:@/tmp/.ICE-unix/904,unix/mine:/tmp/.ICE-unix/904
DESKTOP_AUTOSTART_ID=108f3cd4a975493676156162618053321600000009040000
GIO_LAUNCHED_DESKTOP_FILE=/usr/share/applications/org.gnome.Shell.desktop
GIO_LAUNCHED_DESKTOP_FILE_PID=938
*# 
*# echo $PATH
/usr/local/bin/FjSymlinks:/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl
*#

Checking the file properties of gnome-session in Thunar, it describes it as being a shell.

With regard to not using Gnome:
Originally, I was attracted to Wayland because of the way it isolates each process or application, and plumped for Gnome on the basis that it is supposed to be furthest along in becoming fully Wayland compatible. I noticed that in an unrelated thread, you pointed out that Xfce could be run under Xwayland. However, the problem is that processes and applications running in Xwayland don't benefit from the improved isolation. While I can live with this for a few particularly favoured applications like Thunar, I would prefer to keep as much of my system as practical fully Wayland compatible.

I am not fixated on Gnome, and will certainly consider alternatives. As it is, while it is annoying, unless I try to run something not in the $PATH, it has absolutely zero affect on performance. The main thing I am worried about is the possibility it indicates something wrong at a more fundamental level.

Irvine

Edited for missing words

Last edited by IrvineHimself (2019-06-27 10:17:29)

seth · 2019-06-27 12:35:30

Do you run into this funky branch right on the top of gnome-session (just add some "/usr/bin/date > /tmp/gnome-session.date" above the exec and check the file existence):

if [ "x$XDG_SESSION_TYPE" = "xwayland" ] &&
   [ "x$XDG_SESSION_CLASS" != "xgreeter" ] &&
   [  -n "$SHELL" ] &&
   grep -q "$SHELL" /etc/shells &&
   ! (echo "$SHELL" | grep -q "false") &&
   ! (echo "$SHELL" | grep -q "nologin"); then
  if [ "$1" != '-l' ]; then
    exec bash -c "exec -l '$SHELL' -c '$0 -l $*'"
  else
    shift
  fi
fi

Arch Linux

#1 2019-06-25 15:05:23

[solved] Wayland: Path has double entries for the jre and perl?

#2 2019-06-25 19:36:28

Re: [solved] Wayland: Path has double entries for the jre and perl?

#3 2019-06-26 05:12:53

Re: [solved] Wayland: Path has double entries for the jre and perl?

#4 2019-06-26 07:22:41

Re: [solved] Wayland: Path has double entries for the jre and perl?

#5 2019-06-26 08:59:47

Re: [solved] Wayland: Path has double entries for the jre and perl?

#6 2019-06-26 09:02:31

Re: [solved] Wayland: Path has double entries for the jre and perl?

#7 2019-06-26 09:24:47

Re: [solved] Wayland: Path has double entries for the jre and perl?

#8 2019-06-26 10:33:09

Re: [solved] Wayland: Path has double entries for the jre and perl?

#9 2019-06-26 11:37:04

Re: [solved] Wayland: Path has double entries for the jre and perl?

#10 2019-06-26 12:44:27

Re: [solved] Wayland: Path has double entries for the jre and perl?

#11 2019-06-26 13:17:30

Re: [solved] Wayland: Path has double entries for the jre and perl?

#12 2019-06-26 13:45:43

Re: [solved] Wayland: Path has double entries for the jre and perl?

#13 2019-06-26 13:52:42

Re: [solved] Wayland: Path has double entries for the jre and perl?

#14 2019-06-26 14:11:41

Re: [solved] Wayland: Path has double entries for the jre and perl?

#15 2019-06-26 14:59:57

Re: [solved] Wayland: Path has double entries for the jre and perl?

#16 2019-06-26 15:11:01

Re: [solved] Wayland: Path has double entries for the jre and perl?

#17 2019-06-26 15:15:29

Re: [solved] Wayland: Path has double entries for the jre and perl?

#18 2019-06-26 15:44:07

Re: [solved] Wayland: Path has double entries for the jre and perl?

#19 2019-06-26 15:48:54

Re: [solved] Wayland: Path has double entries for the jre and perl?

#20 2019-06-26 16:33:45

Re: [solved] Wayland: Path has double entries for the jre and perl?

#21 2019-06-26 19:33:24

Re: [solved] Wayland: Path has double entries for the jre and perl?

#22 2019-06-27 04:50:51

Re: [solved] Wayland: Path has double entries for the jre and perl?

#23 2019-06-27 05:34:14

Re: [solved] Wayland: Path has double entries for the jre and perl?

#24 2019-06-27 10:01:45

Re: [solved] Wayland: Path has double entries for the jre and perl?

#25 2019-06-27 12:35:30

Re: [solved] Wayland: Path has double entries for the jre and perl?

Board footer