You are not logged in.
You can probably plaster over the the original problem by "export DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus" in your zprofile before the startx segment, but that will just hide the problem and I'm running out of ideas why it might not be set.
Is /run/user/1000/bus a directory?
Offline
socket (in /run/user/1000/ - 1000 is your likely UID)
Offline
socket (in /run/user/1000/ - 1000 is your likely UID)
Should we start a new Post? I would really like to pinpoint what is happening...
Last edited by p-scvtvlatvs (2021-10-12 22:28:08)
Offline
Why? It's still the original problem.
I assume that exporting the variable before starting X11 (and gnome) will prevent gnome-session from dbus-launching itself what should give you a clean session and make the original issue go away. We just didn't figure the underlying cause.
Offline
Ok, I've just logout and login with my Zsh and here's the following output:
echo $DBUS_SESSION_BUS_ADDRESS
DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-I5eaKRNqVq,guid=8798ef72fb4332c2c0aa969561660e7c
And here's loginctl session-status update:
How should I proceed?
Last edited by p-scvtvlatvs (2021-10-12 23:01:19)
Offline
Do any of that users startup files use dbus-launch or export DBUS_SESSION_BUS_ADDRESS?
If you create a new user, log into the new user from a terminal does the new users environment have
DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/something,guid=somethingelse
or is it
unix:path=/run/user/$UID/bus
Offline
None of the user startup files use dbus-launch nor exports DBUS_SESSION_BUS_ADDRESS.
The user has the following:
DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/something,guid=somethingelse
Offline
Is this from a console login or also gnome?
ls /etc/skel
loginctl session-status # for the new user
Offline
Offline
Paste all the files in /etc/skel - where do they come from?
(Don't say you don't remember, you're "relatively new to Arch" - everyone's meanwhile secretly well aware that this is either a derivate or you used some crap script or followed a shitty youtube tutorial. Knowing the broken source will give us at least a chance to tell you what is broken about it before the thread gets binnded)
You're running a GUI session w/ the user "servus" - don't.
We want to figure the state of the system *before* gnome dbus-launches itself (though I expect in that case $DBUS_SESSION_BUS_ADDRESS will likewise not be set)
Offline
Here are all the /etc/skel file content(s):
.bashrc
https://termbin.com/pikr
.bash_profile
https://termbin.com/yzfh
.bash_logout
https://termbin.com/167iu
I was using Zsh by the way and here's the updated loginctl session-status:
I changed the SHELL to /bin/bash and here's the output of:
loginctl session-status
Last edited by p-scvtvlatvs (2021-10-14 14:56:22)
Offline
If I do
env | grep DBUS
nothing is returned, just like you just said.
Last edited by p-scvtvlatvs (2021-10-14 14:54:42)
Offline
So there's nothing special in those files, but you haven't explained how they ended up being there.
There's something severely broken about the login process and we need to know how you installed the system in order to get a remote chance to figure what it is.
Sanity check
grep -r systemd /usr/lib/pam.d
Offline
I installed Arch following the Installation Guide:
https://wiki.archlinux.org/title/Installation_guide
The sanity check:
Offline
Ok, sorry - the skel's are actually in bash (since 11 years) - I'll have to pay closer attention to my next bash update on why they're not extracted here… (not in NoExtract)
The pam config looks ok.
Again: you can probably plaster over the problm by exporting the proper DBUS_SESSION_BUS_ADDRESS before starting gnome, but I've really no idea why pam_systemd doesn't set them…
Have you ever posted a complete system journal (sudo journalctl -b) in this thread?
Offline
Have you ever posted a complete system journal (sudo journalctl -b) in this thread?
No, I haven't... here it goes:
Offline
That's a session log, "sudo" is important here.
Offline
That's a session log, "sudo" is important here.
Got it, here you go:
Offline
It sure looks like systemd-logind is used, gnome whines around
Oct 12 21:07:25 hydrivm gnome-session[391]: gnome-session-binary[391]: WARNING: Failed to upload environment to systemd: GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Name "org.freedesktop.systemd1" does not exist
Oct 12 21:07:25 hydrivm gnome-session-binary[391]: WARNING: Failed to upload environment to systemd: GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Name "org.freedesktop.systemd1" does not exist
Oct 12 21:07:25 hydrivm gnome-session[391]: gnome-session-binary[391]: WARNING: Failed to reset failed state of units: GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Name "org.freedesktop.systemd1" does not exist
Oct 12 21:07:25 hydrivm gnome-session-binary[391]: WARNING: Failed to reset failed state of units: GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Name "org.freedesktop.systemd1" does not exist
Oct 12 21:07:25 hydrivm gnome-session[391]: gnome-session-binary[391]: WARNING: Falling back to non-systemd startup procedure due to error: GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Name "org.freedesktop.systemd1" does not exist
Oct 12 21:07:25 hydrivm gnome-session-binary[391]: WARNING: Falling back to non-systemd startup procedure due to error: GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Name "org.freedesktop.systemd1" does not exist
Oct 12 21:07:25 hydrivm gnome-session[391]: gnome-session-binary[391]: WARNING: Could not get session id for session. Check that logind is properly installed and pam_systemd is getting used at login.
Oct 12 21:07:25 hydrivm gnome-session-binary[391]: WARNING: Could not get session id for session. Check that logind is properly installed and pam_systemd is getting used at login.
because it's using the wrong™ dbus socket…
Do you unset the environment? Your shell scripts all have /bin/env for a shebang. Why and is there maybe somewhere some "env -i"?
grep -r DBUS_SESSION_BUS_ADDRESS ~ /etc
Offline
It sure looks like systemd-logind is used, gnome whines around
Do you unset the environment? Your shell scripts all have /bin/env for a shebang. Why and is there maybe somewhere some "env -i"?
No, I don't use "env -i". I just use
#!/usr/bin/env /usr/bin/zsh
I remember I was studying from an LPI certification book and it recommended the use of env, but I'm not sure why...
Here's grep -r DBUS_SESSION_BUS_ADDRESS ~ /etc output:
Last edited by p-scvtvlatvs (2021-10-14 21:06:37)
Offline
Let's see /home/servus/.xdg/runtime/nvim/bundle/vimtex/doc/vimtex.txt, /home/servus/.xdg/config/zsh/.zshrc and /home/servus/.xdg/config/zsh/.zshrc.zni
Offline
~/.xdg/runtime/nvim/bundle/vimtex/doc/vimtex.txt:
https://termbin.com/fyfg
~/.xdg/config/zsh/.zshrc
https://termbin.com/azkj
~/.xdg/config/zsh/.zshrc.zni
https://termbin.com/6qg4
Last edited by p-scvtvlatvs (2021-10-15 18:25:50)
Offline
I just wanted to drop in because I ran into this thread because I had an arch install that worked just fine for months, but all of the sudden gnome-keyring just stopped working. Geary and Mailspring won't load. I tried messing with the packages looking at pacman.log but to no avail. After reading this thread, I'm getting the same weird location for the DBUS_SESSION_BUS_ADDRESS of "unix:abstract=/tmp/dbus-ogegOVEr2d,guid=d549865bf7dd54a94192ee66616dc073", and I also have recently installed virtualbox about a month ago on this machine.
My install largely followed this article: https://jherrlin.github.io/posts/arch-install/ but one weird thing about my install that happened was that I needed to include "dbus-update-activation-environment --all" in my .xinitrc, If I had my usual "dbus-update-activation-environment --systemd DISPLAY", gnome-terminal threw some error code 8 and refused to start. That was always the case with this system.
Now following the mysterious 'event' about 2 weeks ago where I stopped being able to use keyrings, any attempt to include an export/eval for gnome-keyring-daemon my .xinitrc stops my ability to use a pw-protected ssh key. without it, it never remembers the password, the keyring doesn't work, but I can still enter in the password in the command line it just asks me every time. This seems to make sense if the keyring system is broken.
Last edited by NGeorgescu (2021-10-18 19:45:37)
Offline
You're supposed to include /etc/X11/xinit/xinitrc.d/ which would import DISPLAY & XAUTHORITY and I assume XAUTHORITY was causing you trouble.
Doesn't explain the offset DBUS_SESSION_BUS_ADDRESS, though.
I also have recently installed virtualbox about a month ago on this machine.
Does this correlate w/ the appearance of the issue? Did you try to remove virtualbox again?
Offline
I don't know if it correlates with the disappearance.
- Sept 20th installed linux-headers (for vbox), did an -Syu, and
yay -Rnscc go
- Sept 21st installed rdkit and installed and then uninstalled inchi
- Sept 27th installed Julia.
- Oct 2nd,
yay -Syu
- Oct 3rd installed rmlint.
- October 4th I installed stockfish and chessx.
- On October 6th I did a
yay -Rnscc gnome-builder
It was on Friday October 8th, after I rebooted my system, that I discovered that this was happening. My last reboot before that was Sept 20th when I installed the stuff for vbox.
The inclusion of xinitrc.d has no effect that I can determine.
Edit:
Also: I looked in / excluding /home /proc and /sys for anything that sets dbus session address with grep -rnwI and got:
/usr/share/gtk-doc/html/gio/running-gio-apps.html:120:<p><b><code class="envar">DBUS_SESSION_BUS_ADDRESS</code>. </b>
/usr/share/gtk-doc/html/gio/GTestDBus.html:376:<p>Start a dbus-daemon instance and set DBUS_SESSION_BUS_ADDRESS. After this
/usr/share/gtk-doc/html/gio/GTestDBus.html:454:<p>Unset DISPLAY and DBUS_SESSION_BUS_ADDRESS env variables to ensure the test
/usr/share/doc/systemd/NEWS:3662: * $DBUS_SESSION_BUS_ADDRESS environment variable is set by pam_systemd
/usr/share/doc/systemd/NEWS:4212: * $DBUS_SESSION_BUS_ADDRESS environment variable is not set by
/usr/share/gvfs/mounts/admin.mount:4:Exec=/bin/sh -c 'pkexec /usr/lib/gvfsd-admin "$@" --address $DBUS_SESSION_BUS_ADDRESS --dir $XDG_RUNTIME_DIR' gvfsd-admin
/usr/lib/systemd/user/dbus.socket:6:ExecStartPost=-/usr/bin/systemctl --user set-environment DBUS_SESSION_BUS_ADDRESS=unix:path=%t/bus
/usr/lib/tracker-3.0/trackertestutils/__main__.py:132: os.environ['DBUS_SESSION_BUS_ADDRESS'] = dbus_session_bus_address
/usr/lib/tracker-3.0/trackertestutils/__main__.py:136: os.environ['DBUS_SESSION_BUS_ADDRESS'] = sandbox.get_session_bus_address()
/usr/lib/tracker-3.0/trackertestutils/dconf.py:45: self.env['DBUS_SESSION_BUS_ADDRESS'] = sandbox.get_session_bus_address()
As well as a bunch of lines with ruby-dbus, which was installed a long time ago back in september. I removed ruby-dbus, it didn't do anything.
Nothing else I can see obviously does anything with the dbus address. "echo $XDG_RUNTIME_DIR" yields "/run/user/1000".
Last edited by NGeorgescu (2021-10-19 12:47:35)
Offline