[SOLVED] Failed to connect to bus: $XDG_RUNTIME_DIR not defined

sarthak1 · 2021-12-09 19:14:16

EDIT:
Error was related to the faulty permissions of the /usr/bin/systemctl file.

$ stat /usr/bin/systemctl
...
Access: (4755/-rwsr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
...

(#19 and forth)
------------------------------------------------------------------------------------------
I am getting

Failed to connect to bus: $DBUS_SESSION_BUS_ADDRESS and $XDG_RUNTIME_DIR not defined

On running "systemctl --user" (without sudo, or as root user)
These variables are defined,

echo $XDG_RUNTIME_DIR/ $DBUS_SESSION_BUS_ADDRESS 
/run/user/1000/ unix:path=/run/user/1000/bus

I read the Systemd/User#Environment_variables wiki and added the variables to ~/.config/environment.d, and few other thing mentioned there.

Also,

$ journalctl --user:
No journal files were opened due to insufficient permissions

I can't exactly find anything related to this, usually people just used sudo
Did read couple other posts,

Output of loginctl user-status, and loginctl session-status
And the permissions:

$ ls -l /run/user/1000/bus
srw-rw-rw- 1 sarthak sarthak 0 Dec  9 23:44 /run/user/1000/bus

I did a system update a while ago, there was a ucode update, which failed because EFI partition was not mounted, and my system froze on reboot. So I chrooted, and installed linux and did mkinitcpio -P

And another thing, a week ago I accidentally deleted my home subvolume (Btrfs), and then made it again as root user, then gave myself permissions.

ls -ld ~
drwxr-xr-x 1 sarthak wheel 368 Dec 10 00:34 /home/sarthak

I did follow installation guide (not all of General recommendation wiki yet). And other than this, my system works fine

Last edited by sarthak1 (2021-12-10 17:52:51)

seth · 2021-12-09 21:25:43

type systemctl # if that doesn't make you go d'ohhh!
dbus-send --session --print-reply --dest=org.freedesktop.DBus /org/freedesktop/DBus org.freedesktop.DBus.ListNames | sed '/string/!d; s/^\s*string //g'

sarthak1 · 2021-12-09 22:11:25

$ type systemctl
systemctl is hashed (/usr/bin/systemctl)

And for the second command: ix.io

seth · 2021-12-10 07:53:01

I read the Systemd/User#Environment_variables wiki and added the variables to ~/.config/environment.d, and few other thing mentioned there.

Before or after? Either way, don't - systemd/logind sets and imports the variables into the session - doing so on top will distort results (the variables being exported to the shell but not the session)

$ journalctl --user:
No journal files were opened due to insufficient permissions

id
ls -lR /{var,run}/log/journal

Also the session status has

Dec 09 23:51:17 elixir sudo[1898]:  sarthak : TTY=pts/0 ; PWD=/home/sarthak ; USER=root ; COMMAND=/usr/bin/journalctl --user

while your OP suggested no sudo invocation - How exactly is your approach here, because also

I can't exactly find anything related to this, usually people just used sudo

which is always a great way to completely shred your access rights…
Therefore

stat /run/user/1000/bus

sarthak1 · 2021-12-10 09:34:50

Uhm.. yes I read that wiki before the Xorg part as I use wayland. Could you tell me how to check if specifically logind imports the variables?
The `printenv` does list those two variables
I removed the variables from my bashrc, and deleted the environment.d file, and checked again.
My bash_profile has only one line

[ "$(tty)" = "/dev/tty1" ] && exec dbus-run-session sway

After someone suggested that in unixporrn, otherwise it was simply `exec sway`

seth wrote:

Also the session status has
Dec 09 23:51:17 elixir sudo[1898]:  sarthak : TTY=pts/0 ; PWD=/home/sarthak ; USER=root ; COMMAND=/usr/bin/journalctl --user
while your OP suggested no sudo invocation - How exactly is your approach here

I don't get it, I used the commands without sudo, `loginctl session-status`
Could you please link a wiki page where I can understand the output of session-status?
loginctl (1) isn't much descriptive

$ id
uid=1000(sarthak) gid=1000(sarthak) groups=1000(sarthak),998(wheel)

$ ls -lR /{var,run}/log/journal
This permission denied error for /var came when I updated the system too.
I did not restore this subvolume (which is now a normal directory, possibly created by systemd) when I rolled back to a snapshot (and deleted my home directory), could this be related?
I have no clue about the expected access rights of /var

$ stat /run/user/1000/bus

sarthak1 · 2021-12-10 10:56:34

I checked the /var/log again as root user, and it still gives permission denied error. It might be that the /var/log is still a read-only subvolume, from the last snapshot, which was readonly. But it does not list in the `sudo btrfs subvolume list /`
... only had home and root

I deleted /var/log and rebooted again, now the it has some files

$ ls /var/log/
btmp  lastlog  private	wtmp

And here's the updated, although there seems to be no change. http://ix.io/3Hzv
and with sudo, $ sudo ls -lR /{var,run}/log/journal

seth · 2021-12-10 11:03:37

You don't have a persistent storage location.
The more interesting aspect is the assertion that you didn't run "journalctl --user" under sudo - because you did.

alias
printenv

sarthak1 · 2021-12-10 11:07:41

but I didn't...
alias gives nothing.

$ type journalctl
journalctl is hashed (/usr/bin/journalctl)

Here's printenv: http://ix.io/3HzG

There's nothing related to dbus in /tmp

$ ls /tmp
systemd-private-8e57365fa94d45ed865b6ef44660af56-iwd.service-t3fqyG
systemd-private-8e57365fa94d45ed865b6ef44660af56-systemd-logind.service-qTQ3Ut
Temp-edc3fe6f-b4db-4c50-9103-2500274a9a62

Can you explain

seth wrote:

You don't have a persistent storage location.

?

Last edited by sarthak1 (2021-12-10 11:43:50)

seth · 2021-12-10 13:11:18

https://man.archlinux.org/man/journald. … en#OPTIONS

The interesting bit in your last post is

DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-SdyGEKsQib,guid=abbd46f93c04a5b7a753272a61b32ebb

Which is wrong, but recently emerged for other users/configs.

Possible cause:

After someone suggested that in unixporrn

Someone in this thread suggests that someone at unixporn rtfm: https://man.archlinux.org/man/core/dbus … ssion.1.en

So at least undo that and make sure that the proper session bus is exported.

sarthak1 · 2021-12-10 13:45:13

Last edited by sarthak1 (2021-12-10 13:54:54)

sarthak1 · 2021-12-10 13:49:27

seth wrote:

So at least undo that and make sure that the proper session bus is exported.

It was already `exec sway` though.
I changed it again. Nothing happened

seth wrote:

The interesting bit in your last post is
DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-SdyGEKsQib,guid=abbd46f93c04a5b7a753272a61b32ebb
Which is wrong, but recently emerged for other users/configs.

So..... how do I fix this?

seth · 2021-12-10 13:59:34

What's the state before you run sway (ie. on the linux console)?

sarthak1 · 2021-12-10 14:40:14

Removing dbus-session-run changed the $DBUS_SESSION_BUS_ADDRESS to unix:path=/run/user/1000/bus
This value was set correct when I launched sway using `exec sway` in bash_profile.

The error still persists..
I ran all the commands in tty, this is the `script` file. I don't know how to remove the color codes / control characters. It is prints fine in terminal though
DBus address specifically:

DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus

So, I guess running dbus-sesssion for sway made it worse, instead of fixing it?

seth · 2021-12-10 15:09:58

The interesting thing to run in the console would be "systemctl --user"
The script esp. lacks the timing data required for replay, but there's certainly some "sudo" in there.

The error you receive is common if you run "systemctl --user" w/ a different UID, if it's not sudo, did you maybe suid it??

So, I guess running dbus-sesssion for sway made it worse, instead of fixing it?

Yes. You're explicitly creating an isolated dbus context.

sarthak1 · 2021-12-10 15:33:42

Same error on `systemctl --user`: http://ix.io/3HBu

I used sudo for `ls /run/log/journal/<long string>` as it gave permission denied.
The /var/log/journal is again not created.
$ ls -lR /{var,run}/log/journal

sarthak1 · 2021-12-10 15:37:32

Seth wrote:

The error you receive is common if you run "systemctl --user" w/ a different UID, if it's not sudo, did you maybe suid it??

Will I have to create a new user for that?
I don't understand suid. I installed arch 8 days ago, and I am still at core utilities part of general recommendations wiki

Last edited by sarthak1 (2021-12-10 15:45:32)

seth · 2021-12-10 15:40:06

The /var/log/journal is again not created.

Did you see the linked journald.conf manpage in #9?

Will I have to create a new user for that?

No, and you should not do that either.

Maybe we're looking the wrong direction…

hostnamectl

sarthak1 · 2021-12-10 15:48:16

ah sorry for the late edit. I was on my mobile that time.

I skimmed the journald.conf manpage but didn't understand much
$ hostnamectl

seth · 2021-12-10 15:59:46

hostname is a dead-end

the journald.conf manpage wrote:

Storage=
Controls where to store journal data. One of "volatile", "persistent", "auto" and "none". If "volatile", journal log data will be stored only in memory, i.e. below the /run/log/journal hierarchy (which is created if needed). If "persistent", data will be stored preferably on disk, i.e. below the /var/log/journal hierarchy (which is created if needed), with a fallback to /run/log/journal (which is created if needed), during early boot and if the disk is not writable. "auto" behaves like "persistent" if the /var/log/journal directory exists, and "volatile" otherwise (the existence of the directory controls the storage mode). "none" turns off all storage, all log data received will be dropped (but forwarding to other targets, such as the console, the kernel log buffer, or a syslog socket will still work). Defaults to "auto" in the default journal namespace, and "persistent" in all others.
Note that journald will initially use volatile storage, until a call to journalctl --flush (or sending SIGUSR1 to journald) will cause it to switch to persistent logging (under the conditions mentioned above). This is done automatically on boot via "systemd-journal-flush.service".
Note that when this option is changed to "volatile", existing persistent data is not removed. In the other direction, journalctl(1) with the --flush option may be used to move volatile data to persistent storage.

I don't understand suid.

stat /usr/bin/systemctl

Also

strace -fto systemctl.strace systemctl --user

and post the systemctl.strace file.

sarthak1 · 2021-12-10 16:07:44

I cannot use the strace commant, same error variables not defined, and... what's the path to systemctl.strace file?

$ stat /usr/bin/systemctl
  File: /usr/bin/systemctl
  Size: 243904    	Blocks: 480        IO Block: 4096   regular file
Device: 0,32	Inode: 22997       Links: 1
Access: (4755/-rwsr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2021-12-09 22:39:39.109218663 +0530
Modify: 2021-11-29 19:12:03.000000000 +0530
Change: 2021-12-03 05:25:37.082166219 +0530
 Birth: 2021-12-03 03:00:34.876390241 +0530

sarthak1 · 2021-12-10 16:14:11

I had uncommented and changed few options in the /etc/systemd/journald.conf

SyncIntervalSec=5m
SystemMaxUse=10M
SystemMaxFileSize=10M
RuntimeMaxUse=5M

Rest of the file is the default one, i.e. all commented out

seth · 2021-12-10 16:15:56

what's the path to systemctl.strace file?

pwd

However:

Access: (4755/-rwsr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root)

What. The. Fuck.

pacman -Qikk systemd

sudo chmod -s /usr/bin/systemctl

will remove the sticky bit.

How did you install archlinux? What script did you use? What tutorial did you follow?
IOW: Why is that there?

sarthak1 · 2021-12-10 16:36:58

I followed arch wiki's installation guide, and btrfs wiki, till the Reboot part
and then a youtube video to add a user, which is not in the installation guide

I also played around with btrfs subvolumes and EFI stub/systemd-boot, breaking-chrooting the system multiple times...
also, accidentally deleted the root subvolume, and then again accidentally mounted a read only snapshot - it was a mess, although I was able to fix it.

I can't remember more f*ck-ups right now

But thanks a lot!!!
Uhm can you predict the cause for the error?
it seems systemctl doesn't have proper access to users
Sorry and thank you for the extensive help though

Can using systemctl in chroot be cause?

Last edited by sarthak1 (2021-12-10 16:39:57)

seth · 2021-12-10 16:54:42

Uhm can you predict the cause for the error?

The cause for the error is the sticky bit on systemctl.
The cause for that being there is what I want to know from you.

I'm sorry, but I don't buy your story at all (not the least because theres oc. https://wiki.archlinux.org/title/Instal … stallation -> https://wiki.archlinux.org/title/Genera … mendations -> https://wiki.archlinux.org/title/Users_ … management )
Also the suid didn't randomly drop on that file. I skipped through the yt video you linked and didn't see that kind of nonsense there, so for the moment, that guy's off the hook.
You implied you don't know what suid means, so you didn't come up with that by yourself either.

Usually I don't care all that much (other than informing the user that the yt tutorial they're following is shit), but this here borders on the wrong side of malice and I want to know who's handing out this shit so I can chastise them into the ground.
The sticky bit on systemctl opens control over the system to any user. It's equivalent to a root shell. It has no business being there. For no reason. And anyone suggesting different deserves a headwash.

Also post the output of

pacman -Qikk systemd

so we can be sure there're not further hiccups - at least in that package.

And please always remember to mark resolved threads by editing your initial posts subject - so others will know that there's no task left, but maybe a solution to find.
Thanks.

sarthak1 · 2021-12-10 17:48:37

I know there is there a separate wiki for user and groups, but I took me around 30 hours to install arch, mostly because I chose to read whole btrfs man page, wiki, and FAQ section first, Then I was too exhausted to read another branched wiki just to add a user, so I quietly followed the video. He follows arch wiki, according to him, and I didn't find anything conflicting in it. I know it doesn't prove anything but what can I say..

just a while ago (~4 hours) some some of my friends tried to add my user to systemd-journal group, though I removed it after it didn't fix the issue. really don't know what's the cause.

Here's $ pacman -Qikk systemd.

And, yes I was about to edit the title, was waiting for possible cause so as to paste it at the top of the post, firefox crashed so had to the whole thing again (the first time I ran the command, it said 3 files altered)

Edit: `journalctl --user` gives insufficient permission error, it's because the storage option defaults to "auto", which doesn't write to disk if there's no /var/log/journal directory, and....... this shouldn't cause any more trouble, right?

Last edited by sarthak1 (2021-12-10 18:00:06)

Arch Linux

#1 2021-12-09 19:14:16

[SOLVED] Failed to connect to bus: $XDG_RUNTIME_DIR not defined

#2 2021-12-09 21:25:43

Re: [SOLVED] Failed to connect to bus: $XDG_RUNTIME_DIR not defined

#3 2021-12-09 22:11:25

Re: [SOLVED] Failed to connect to bus: $XDG_RUNTIME_DIR not defined

#4 2021-12-10 07:53:01

Re: [SOLVED] Failed to connect to bus: $XDG_RUNTIME_DIR not defined

#5 2021-12-10 09:34:50

Re: [SOLVED] Failed to connect to bus: $XDG_RUNTIME_DIR not defined

#6 2021-12-10 10:56:34

Re: [SOLVED] Failed to connect to bus: $XDG_RUNTIME_DIR not defined

#7 2021-12-10 11:03:37

Re: [SOLVED] Failed to connect to bus: $XDG_RUNTIME_DIR not defined

#8 2021-12-10 11:07:41

Re: [SOLVED] Failed to connect to bus: $XDG_RUNTIME_DIR not defined

#9 2021-12-10 13:11:18

Re: [SOLVED] Failed to connect to bus: $XDG_RUNTIME_DIR not defined

#10 2021-12-10 13:45:13

Re: [SOLVED] Failed to connect to bus: $XDG_RUNTIME_DIR not defined

#11 2021-12-10 13:49:27

Re: [SOLVED] Failed to connect to bus: $XDG_RUNTIME_DIR not defined

#12 2021-12-10 13:59:34

Re: [SOLVED] Failed to connect to bus: $XDG_RUNTIME_DIR not defined

#13 2021-12-10 14:40:14

Re: [SOLVED] Failed to connect to bus: $XDG_RUNTIME_DIR not defined

#14 2021-12-10 15:09:58

Re: [SOLVED] Failed to connect to bus: $XDG_RUNTIME_DIR not defined

#15 2021-12-10 15:33:42

Re: [SOLVED] Failed to connect to bus: $XDG_RUNTIME_DIR not defined

#16 2021-12-10 15:37:32

Re: [SOLVED] Failed to connect to bus: $XDG_RUNTIME_DIR not defined

#17 2021-12-10 15:40:06

Re: [SOLVED] Failed to connect to bus: $XDG_RUNTIME_DIR not defined

#18 2021-12-10 15:48:16

Re: [SOLVED] Failed to connect to bus: $XDG_RUNTIME_DIR not defined

#19 2021-12-10 15:59:46

Re: [SOLVED] Failed to connect to bus: $XDG_RUNTIME_DIR not defined

#20 2021-12-10 16:07:44

Re: [SOLVED] Failed to connect to bus: $XDG_RUNTIME_DIR not defined

#21 2021-12-10 16:14:11

Re: [SOLVED] Failed to connect to bus: $XDG_RUNTIME_DIR not defined

#22 2021-12-10 16:15:56

Re: [SOLVED] Failed to connect to bus: $XDG_RUNTIME_DIR not defined

#23 2021-12-10 16:36:58

Re: [SOLVED] Failed to connect to bus: $XDG_RUNTIME_DIR not defined

#24 2021-12-10 16:54:42

Re: [SOLVED] Failed to connect to bus: $XDG_RUNTIME_DIR not defined

#25 2021-12-10 17:48:37

Re: [SOLVED] Failed to connect to bus: $XDG_RUNTIME_DIR not defined

Board footer