You are not logged in.

#26 2016-10-14 21:17:02

seth
Member
Registered: 2012-09-03
Posts: 49,979

Re: I want to say solved, but [FIXED] PolicyKit woes

Do you have trouble mounting /run?
Is /run/user/$UID mounted?

The problem will be the unset $DBUS_SESSION_BUS_ADDRESS. Since it should be /run/user/$UID/bus, the problem might be to create the socket there.

Offline

#27 2016-10-15 08:41:19

Roken
Member
From: South Wales, UK
Registered: 2012-01-16
Posts: 1,251

Re: I want to say solved, but [FIXED] PolicyKit woes

Well, /run/user/$UID is mounted. However, you are right about DBUS_SESSION_BUS_ADDRESS

With the problematic launch:

$ ls /run/user/1000
bus  gnupg  pulse  systemd

$ env | grep DBUS
DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-F83D9BiRYr,guid=b426187d67e2283fffbc198d5801e9ec

After killall xfce4-session and re-logging with lightdm

$ ls /run/user/1000
bus  dconf  gnupg  gvfs  pulse  systemd

$ env | grep DBUS
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus

The problem is, I still don't know where the proplematic session is being launched from, and it worries me that it's a root process.


Ryzen 5900X 12 core/24 thread - RTX 3090 FE 24 Gb, Asus Prime B450 Plus, 32Gb Corsair DDR4, Cooler Master N300 chassis, 5 HD (1 NvME PCI, 4SSD) + 1 x optical.
Linux user #545703

Offline

#28 2016-10-15 12:45:27

Lone_Wolf
Member
From: Netherlands, Europe
Registered: 2005-10-04
Posts: 11,868

Re: I want to say solved, but [FIXED] PolicyKit woes

lightdm-log in post #17

[+27.43s] DEBUG: Activating VT 7

from post #25

$ loginctl show-session $XDG_SESSION_ID
Id=c3
User=1000
Name=steve
Timestamp=Fri 2016-10-14 20:59:35 BST
TimestampMonotonic=63069833
VTNr=7
$ env | grep XDG
XDG_VTNR=7

Before systemd-logind came along, X terminals were on vt7 (ck-launch from consolekit was used to achieve that).
systemd-logind opens X on the virtual screens where it's launched from , but there are several ways to override that.
startx -- vt7 is one of them.

please post your current ~/.xinitrc , ~/.xsession , ~/.bashrc , ~/.bash_profile and ~/.xserverrc .

Last edited by Lone_Wolf (2016-10-15 12:47:29)


Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.


(A works at time B)  && (time C > time B ) ≠  (A works at time C)

Offline

#29 2016-10-15 14:23:43

loqs
Member
Registered: 2014-03-06
Posts: 17,192

Re: I want to say solved, but [FIXED] PolicyKit woes

Would suggest a slightly different approach to Lone_Wolf Stop / Disable all display managers and log into a tty using a freshly created user and check if $DBUS_SESSION_BUS_ADDRESS is set correctly.
Edit:
Change DBUS_SESSION_ID to DBUS_SESSION_BUS_ADDRESS mistake spotted by damjan.

Last edited by loqs (2016-10-15 15:08:37)

Offline

#30 2016-10-15 14:57:46

damjan
Member
Registered: 2006-05-30
Posts: 451

Re: I want to say solved, but [FIXED] PolicyKit woes

loqs wrote:

Would suggest a slightly different approach to Lone_Wolf Stop / Disable all display managers and log into a tty using a freshly created user and check if DBUS_SESSION_ID is set correctly.

I guess you mean $DBUS_SESSION_BUS_ADDRESS (I don't have DBUS_SESSION_ID in tty nor in KDE).

Offline

#31 2016-10-15 20:14:43

Roken
Member
From: South Wales, UK
Registered: 2012-01-16
Posts: 1,251

Re: I want to say solved, but [FIXED] PolicyKit woes

Before I change anything, I made a point of forcing X onto TTY7. Now if that turns out to be the problem, surely that's a regression?


Ryzen 5900X 12 core/24 thread - RTX 3090 FE 24 Gb, Asus Prime B450 Plus, 32Gb Corsair DDR4, Cooler Master N300 chassis, 5 HD (1 NvME PCI, 4SSD) + 1 x optical.
Linux user #545703

Offline

#32 2016-10-15 20:18:16

jasonwryan
Anarchist
From: .nz
Registered: 2009-05-09
Posts: 30,424
Website

Re: I want to say solved, but [FIXED] PolicyKit woes

Roken wrote:

forcing

That never ends well... Also, exactly the sort of thing that should have been mentioned in #1.


Arch + dwm   •   Mercurial repos  •   Surfraw

Registered Linux User #482438

Offline

#33 2016-10-15 20:38:27

loqs
Member
Registered: 2014-03-06
Posts: 17,192

Re: I want to say solved, but [FIXED] PolicyKit woes

Roken wrote:

Before I change anything, I made a point of forcing X onto TTY7.

https://git.archlinux.org/svntogit/pack … es/lightdm
The default lightdm.conf as supplied by arch is patched so that lightdm will start on the first available tty from 7 upwards.
So what exactly do you mean by forced?

Offline

#34 2016-10-16 06:53:15

Roken
Member
From: South Wales, UK
Registered: 2012-01-16
Posts: 1,251

Re: I want to say solved, but [FIXED] PolicyKit woes

I appear to be mis-representing. When the change was originally introduced to start X on the login TTY I changed it to always start on tty7, but that change appears to have since been overwritten by an update, so it seems I'm no longer forcing TTY7, lightdm, however, may be, as suggested by logs

EDIT: Confirmed, it isn't something I've done, it's lightdm default behaviour (confirmed by temprarilly changing the default behaviour in lightdm).

Last edited by Roken (2016-10-16 07:03:04)


Ryzen 5900X 12 core/24 thread - RTX 3090 FE 24 Gb, Asus Prime B450 Plus, 32Gb Corsair DDR4, Cooler Master N300 chassis, 5 HD (1 NvME PCI, 4SSD) + 1 x optical.
Linux user #545703

Offline

#35 2016-10-16 07:49:13

nlern
Member
From: West Bengal, India
Registered: 2015-06-29
Posts: 51

Re: I want to say solved, but [FIXED] PolicyKit woes

I recently reinstalled Arch with LXDE on my PC and then was having trouble auto-mounting partitions in PCMan File Manager.  My problems were that the partitions were not showing in PCMan File Manager to begin with and I wanted to mount them without any password prompt.  Then I came across this site which solved my first problem.  Then I followed this Arch Wiki entry and my second problem was also solved.  Hope it helps.

Offline

#36 2016-10-16 16:48:46

seth
Member
Registered: 2012-09-03
Posts: 49,979

Re: I want to say solved, but [FIXED] PolicyKit woes

Roken wrote:

Before I change anything, I made a point of forcing X onto TTY7. Now if that turns out to be the problem, surely that's a regression?

I think, Lone_Wolf was just pointing out some oddity which *might* be caused by ck-launch.
But you had this trouble w/ startx all along, didn't you?

Does anybody here around use lightdm + xfce and encounter this issue, notably "dbus-launch"

@Roken
have ~/bin/dbus-launch (ie. somewhere up in $PATH)

#!/bin/sh
"$@"

;-)

Offline

#37 2016-10-16 17:39:38

loqs
Member
Registered: 2014-03-06
Posts: 17,192

Re: I want to say solved, but [FIXED] PolicyKit woes

There is also the outstanding information requests from posts #28 and #29.

Offline

#38 2016-10-16 19:39:50

Roken
Member
From: South Wales, UK
Registered: 2012-01-16
Posts: 1,251

Re: I want to say solved, but [FIXED] PolicyKit woes

Sorry, Missed the request:

#!/bin/sh
#
# ~/.xinitrc
#
# Executed by startx (run your window manager from here)

if [ -d /etc/X11/xinit/xinitrc.d ]; then
  for f in /etc/X11/xinit/xinitrc.d/*; do
    [ -x "$f" ] && . "$f"
  done
  unset f
fi

xset +fp /usr/share/fonts/local
xset fp rehash
xset s off
xset -dpms

# exec gnome-session
# exec startkde
# exec startxfce4
#xfce4-session

# ...or the Window Manager of your choice
#dbus-launch --exit-with-session startxfce4

case "$1" in
	    openbox) exec openbox-session ;;
	    xfce) exec xfce4-session ;;
	    gnome3) exec gnome-session ;;
	    kde) exec startkde ;;
	    cinnamon) exec gnome-session-cinnamon ;;
	    razor-qt) exec razor-session ;;
	    lxde) exec lxsession ;;
	    mate) exec mate-session ;;
	    *) exec $DEFAULTSESSION
esac
#exec enlightenment_start
#!/bin/sh

#
# ~/.xsession
#
# Executed by xdm/gdm/kdm at login
#

/bin/bash --login -i ~/.xinitrc
# ~/.bashrc: executed by bash(1) for non-login shells.
# see /usr/share/doc/bash/examples/startup-files (in the package bash-doc)
# for examples

# If not running interactively, don't do anything
[ -z "$PS1" ] && return

# don't put duplicate lines in the history. See bash(1) for more options
# don't overwrite GNU Midnight Commander's setting of `ignorespace'.
HISTCONTROL=$HISTCONTROL${HISTCONTROL+:}ignoredups
# ... or force ignoredups and ignorespace
HISTCONTROL=ignoreboth

# append to the history file, don't overwrite it
shopt -s histappend

# for setting history length see HISTSIZE and HISTFILESIZE in bash(1)

# check the window size after each command and, if necessary,
# update the values of LINES and COLUMNS.
shopt -s checkwinsize

# make less more friendly for non-text input files, see lesspipe(1)
#[ -x /usr/bin/lesspipe ] && eval "$(SHELL=/bin/sh lesspipe)"

# set variable identifying the chroot you work in (used in the prompt below)
if [ -z "$debian_chroot" ] && [ -r /etc/debian_chroot ]; then
    debian_chroot=$(cat /etc/debian_chroot)
fi

# set a fancy prompt (non-color, unless we know we "want" color)
case "$TERM" in
    xterm-color) color_prompt=yes;;
esac

# uncomment for a colored prompt, if the terminal has the capability; turned
# off by default to not distract the user: the focus in a terminal window
# should be on the output of commands, not on the prompt
force_color_prompt=yes

if [ -n "$force_color_prompt" ]; then
    if [ -x /usr/bin/tput ] && tput setaf 1 >&/dev/null; then
	# We have color support; assume it's compliant with Ecma-48
	# (ISO/IEC-6429). (Lack of such support is extremely rare, and such
	# a case would tend to support setf rather than setaf.)
	color_prompt=yes
    else
	color_prompt=yes
    fi
fi

if [ "$color_prompt" = yes ]; then
	PS1='${debian_chroot:+($debian_chroot)}\[\033[0333;32m\]\u@\h\[\033[00m\]:\[\033[01;035m\](\A)\[\033[01;34m\]\w\[\033[00m\]\$ '
else
	PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w\$ '
fi
unset color_prompt force_color_prompt

# If this is an xterm set the title to user@host:dir
case "$TERM" in
xterm*|rxvt*)
    PS1="\[\e]0;${debian_chroot:+($debian_chroot)}\u@\h: \w\a\]$PS1"
    ;;
*)
    ;;
esac

# enable color support of ls and also add handy aliases
if [ -x /usr/bin/dircolors ]; then
    test -r ~/.dircolors && eval "$(dircolors -b ~/.dircolors)" || eval "$(dircolors -b)"
    alias ls='ls --color=auto'
    #alias dir='dir --color=auto'
    #alias vdir='vdir --color=auto'

    alias grep='grep --color=auto'
    #alias fgrep='fgrep --color=auto'
    #alias egrep='egrep --color=auto'
fi

# some more ls aliases
#alias ll='ls -l'
#alias la='ls -A'
#alias l='ls -CF'

function vboxupdate() 
{
	dkms install vboxhost/$(pacman -Q virtualbox|awk {'print $2'}|sed 's/\-.\+//') -k $(uname -a | awk {'print $3'})/x86_64
}

export -f vboxupdate

# Alias definitions.
# You may want to put all your additions into a separate file like
# ~/.bash_aliases, instead of adding them here directly.
# See /usr/share/doc/bash-doc/examples in the bash-doc package.

if [ -f ~/.bash_aliases ]; then
    . ~/.bash_aliases
fi

# enable programmable completion features (you don't need to enable
# this, if it's already enabled in /etc/bash.bashrc and /etc/profile
# sources /etc/bash.bashrc).
if [ -f /etc/bash_completion ] && ! shopt -oq posix; then
    . /etc/bash_completion
fi

export PATH=$PATH:/home/steve/scripts
export MAKEFLAGS='-j 5'
export WINEDLLOVERRIDES='winemenunuilder.exe=d'

echo -e "$(tput setaf 3)Welcome to Tex BASH$(tput setaf 2)\n"

#cat .cow && echo "$(tput setaf 1)" && fortune && echo "$(tput setaf 0)"
sh /home/steve/scripts/bashtop && echo "$(tput setaf 1)" && fortune && echo "$(tput setaf 0)"
#
# ~/.bash_profile
#
PATH=$PATH:/opt/blender
[[ -f ~/.bashrc ]] && . ~/.bashrc
/usr/bin/cat: /home/steve/.xserverrc: No such file or directory

I don't have  DBUS_SESSION_ID


Ryzen 5900X 12 core/24 thread - RTX 3090 FE 24 Gb, Asus Prime B450 Plus, 32Gb Corsair DDR4, Cooler Master N300 chassis, 5 HD (1 NvME PCI, 4SSD) + 1 x optical.
Linux user #545703

Offline

#39 2016-10-16 19:59:52

loqs
Member
Registered: 2014-03-06
Posts: 17,192

Re: I want to say solved, but [FIXED] PolicyKit woes

Roken wrote:

I don't have  DBUS_SESSION_ID

I had corrected that to  $DBUS_SESSION_BUS_ADDRESS unfortunately it still appears to have been unclear.
Would just suggest create a new user then reboot and Change_default_target_to_boot_into to multi-user.target from the bootloader so no permanent changes will be made.
That should stop the display manager service starting for that boot.
Then log into a terminal as the new user and check if $DBUS_SESSION_BUS_ADDRESS is set correctly.
If it is still incorrect then it eliminates the issue being related to xfce/lightdm/any config files specific to your normal user.
If it is set correctly then try for your normal user.
Edit:
Might also be worth checking if $DBUS_SESSION_BUS_ADDRESS is set correctly after logging into an xfce session from lightdm.

Last edited by loqs (2016-10-16 20:06:26)

Offline

#40 2016-10-16 22:50:25

Roken
Member
From: South Wales, UK
Registered: 2012-01-16
Posts: 1,251

Re: I want to say solved, but [FIXED] PolicyKit woes

OK. Disabled the DM and created a new user. After a reboot, logged in the new, test user and DBUS_SESSION_BUS_ID is correctly set. Logged out and logged in the old user and it isn't set at all.

Experimentally, I moved .xinitrx and .xsession for the old user and rebooted. Logged in with the old user and it's still incorrectly set, so whilst we seem to have narrowed it down to the user, I can rule those out.

Now, whilst this does give me a solution in that I can migrate files, user scripts etc. to a new user, I'd rather identify and fix the problem with the old user. Not sure what other files to be looking at, though. I can't see any other dot files in ~/ that would impact, but happy for suggestions (as a very mature user account, there are an awful lot of dot files there).


Ryzen 5900X 12 core/24 thread - RTX 3090 FE 24 Gb, Asus Prime B450 Plus, 32Gb Corsair DDR4, Cooler Master N300 chassis, 5 HD (1 NvME PCI, 4SSD) + 1 x optical.
Linux user #545703

Offline

#41 2016-10-17 00:36:02

loqs
Member
Registered: 2014-03-06
Posts: 17,192

Re: I want to say solved, but [FIXED] PolicyKit woes

Roken wrote:

logged in the old user and it isn't set at all.

Roken wrote:

I'd rather identify and fix the problem with the old user.

https://git.archlinux.org/svntogit/pack … 9b55087b6c

- Remove x11 support; autolaunching is a lot of magic we don't need if we have predictable user buses; unsplit libdbus

The old user worked because although something unidentified unset $DBUS_SESSION_BUS_ADDRESS that would be hidden by the autolaunching of a replacement when x11 started.

Offline

#42 2016-10-17 20:50:12

Roken
Member
From: South Wales, UK
Registered: 2012-01-16
Posts: 1,251

Re: I want to say solved, but [FIXED] PolicyKit woes

OK, the patch failed, and I could put some effort in to make it work, but looking at the commit PKGBUILD, it seems to already have the patches in place, and so I tried that, but no go.

However, and this may help, the same workaround here

killall xfce4-seesion

also fixes my dbus problem (https://bbs.archlinux.org/viewtopic.php?id=216001) which means there's definitely something interfering.

For a laugh, I tried

pacman -Rddn dbus

(well, not for a laugh, but to rule out any config changes I may have made to dbus, though I don't recall any - but hell, it's a system that's been around awhile), and then re-installed (so 1.10.12 as testing branch) and it's made not a blind bit of difference, so I haven't changed dbus behaviour. I see nothing pam related that could account for it, and the fact that a new, test user sets DBUS_SESSION_BUS_ID correctly would suggest that there's nothing fundamentally wrong with my system.

I see nothing in the dot files in home, which suggests a wider config is hitchhiking on my user account.

Now, an oddity. I edited /etc/lightdm/lightdm.conf to make the new, test user the autologin, and it doesn't work. It simply gives me a login prompt, with my main user pre-selected waiting for the PW, which suggests something is selecting my login before lightdm does. I have no idea what, but I suspect if I can find that, I'll find the cuplrit. Ideas?


Ryzen 5900X 12 core/24 thread - RTX 3090 FE 24 Gb, Asus Prime B450 Plus, 32Gb Corsair DDR4, Cooler Master N300 chassis, 5 HD (1 NvME PCI, 4SSD) + 1 x optical.
Linux user #545703

Offline

#43 2016-10-17 21:21:43

loqs
Member
Registered: 2014-03-06
Posts: 17,192

Re: I want to say solved, but [FIXED] PolicyKit woes

Roken wrote:

so I haven't changed dbus behaviour.

Agreed arch has
1.10.8 has

makedepends=('libx11' 'systemd' 'xmlto' 'docbook-xsl')

1.10.10 and 1.10.12 have

makedepends=(systemd xmlto docbook-xsl python yelp-tools doxygen)

To me the important change is the removal of libx11 which ./configure will detect and disable the implicitly enabled --enable-x11-autolaunch build time option

Roken wrote:

the fact that a new, test user sets DBUS_SESSION_BUS_ID correctly would suggest that there's nothing fundamentally wrong with my system.

Agreed it would indicate it is something specific to that user.

Offline

#44 2016-10-17 22:31:37

Roken
Member
From: South Wales, UK
Registered: 2012-01-16
Posts: 1,251

Re: I want to say solved, but [FIXED] PolicyKit woes

OK, so we seem to be getting somewhere, though I can find nothing in ~/ that would account for the behaviour, and nothing in /etc (except the lightdm autologin - which we have established happens after the problem anyway), so, where to now? I've pretty much run out of ideas.
More to the point, logging out and then back in fixes the problem, meaning that it's pre X. That brings me down to .bashrc, in which I can't see anything, but if you have ideas, I'm happy to experiment. (posted in #38).

Last edited by Roken (2016-10-17 22:32:09)


Ryzen 5900X 12 core/24 thread - RTX 3090 FE 24 Gb, Asus Prime B450 Plus, 32Gb Corsair DDR4, Cooler Master N300 chassis, 5 HD (1 NvME PCI, 4SSD) + 1 x optical.
Linux user #545703

Offline

#45 2016-10-17 23:05:13

loqs
Member
Registered: 2014-03-06
Posts: 17,192

Re: I want to say solved, but [FIXED] PolicyKit woes

.bashrc is not my area of expertise,  so my only suggestion would be the simple approach of rename it for testing purposes.

Offline

#46 2016-10-18 07:38:40

seth
Member
Registered: 2012-09-03
Posts: 49,979

Re: I want to say solved, but [FIXED] PolicyKit woes

Create a backup dir, create a subdir "1", move half of your homedir there.
If the problem remains, create "2" and move half of the rest there ...
When the problem is gone, it's in the nubered directory.
Move everything else back and split the dir with the troublemaker into two.
Try whether the problem re-occurs and if (hopefully) not, copy back one of the two troublemakers. If the problem is gone ... you get the point.

A filemanager like mc will be of great help here and maybe "cp -ar ~ /path/to/backup" in case you screw anything ;-)

Offline

#47 2016-10-18 20:26:37

Roken
Member
From: South Wales, UK
Registered: 2012-01-16
Posts: 1,251

Re: I want to say solved, but [FIXED] PolicyKit woes

@seth - you've got the answer and solution. It's something in ~/.config. I don't know what, and after copying to a backup directory, it's impossible to copy everything back. I'm pretty sure I've got most applications stuff back, and most xfce4 config back, but xfce4 stuff in particular is proving most problematic, as are a couple of my scripts which store temp data in /tmp and /dev/shm, but I can fix those in my own good time. The major problem is now gone, but until I fix the outlying issues I'm not marking as solved. I still have remaining stuff in config.bak that I haven't copied over, and I need to walk slowly now to see where the problem was.

Just getting back to something closely resembling my old desktop with no errors is a bonus. I really need to sort my custom scripts out now (they are there for conky, and until I get them working, it is ugly and missing stuff), but at least we are well on the way. A solution I was reluctant to try for those very reasons, but I see these more as challenges than as problems.

Thanks for all the sleepless hours, and thanks for the suggestion :@

EDIT: OK, copied ~/.config/autostart and everything is still good 'ish. I can't remember whether I was using xfce4 compositing or compton, but compton isn't starting. Having said that, no big deal, xfce4 compositing does the job. conky fonts look like crap, but I think that's a conky update rather than my problems. My custom scripts are working again, and no ill effects, except conky is now giving me the most uninformitive error ever, "(standard_in) 1: syntax error", which could be anything. Guess I'll have to test my own scripts one by one to find it's my error.

There are still things that just don't feel quite right, but I can't put my finger on them, though I'm guessing that in those, the problem lies somewhere between the keyboard and the screen (i.e. me), so I'm going to mark this solved.

Thanks to everyone who has contributed to possibly the most elusive (and technically unsolved, but fixed) problem I've ever encountered. I apologise for my attitude at times (I'm looking at you, Jason), but I let my frustration get the better of me. Sorry sad

Last edited by Roken (2016-10-18 21:29:26)


Ryzen 5900X 12 core/24 thread - RTX 3090 FE 24 Gb, Asus Prime B450 Plus, 32Gb Corsair DDR4, Cooler Master N300 chassis, 5 HD (1 NvME PCI, 4SSD) + 1 x optical.
Linux user #545703

Offline

Board footer

Powered by FluxBB