gdbus --system Can't connect?
Tags: pacman, archlinux, dbus, learninginpublic
Published: 2023-08-06 15:17:10

---
title: gdbus --system Can't connect?
published: true
description: Troubleshooting when your system bus doesn't exist...or does it?
tags: pacman, archLinux, dbus, learningInPublic
# cover_image: https://direct_url_to_image.jpg
# Use a ratio of 100:42 for best results.
# published_at: 2023-08-06 13:30 +0000
---

I was uninstalling some orphan packaged on my Arch-based Manjaro Linux system when I noticed something strange...

`Error connecting: Could not connect: No such file or directory`

The uninstall seemed to work correctly, but what was this error? I went looking for the logs...

```
[2023-08-05T09:33:35-0400] [ALPM] running '90-packagekit-refresh.hook'...
[2023-08-05T09:33:35-0400] [ALPM-SCRIPTLET] Error connecting: Could not connect: No such file or directory
```

Huh. Well, the last thing that `pacman` tried before the error was calling `90-packagekit-refresh.hook`. Let's ask `man pacman` what a hook is.

> --hookdir <dir>
           Specify a alternative directory containing hook files (the default is /etc/pacman.d/hooks).
           Multiple hook directories can be specified with hooks in later directories taking precedence over
           hooks in earlier directories.  NOTE: This is an absolute path, and the root path is not
           automatically prepended.

```
ls /etc/pacman.d/hooks                                                     

ls: cannot access '/etc/pacman.d/hooks': No such file or directory
```

That's weird, the default directory doesn't seem to exist. Normally, I'd think this was the issue, except that pacman appeared to run many other hooks with no issues. So, where else are the hooks? 

According to https://wiki.archlinux.org/title/Pacman, section 2.1.8, hooks generally live in `/usr/share/libalpm/hooks`. That directory does exist.

```
cat /usr/share/libalpm/hooks/90-packagekit-refresh.hook

[Trigger]
Type = Package
Operation = Install
Operation = Upgrade
Operation = Remove
Target = *

[Action]
Description = Refreshing PackageKit...
When = PostTransaction
Exec = /bin/sh -c 'gdbus call --system --timeout 30 --dest org.freedesktop.PackageKit --object-path /org/freedesktop/PackageKit --method org.freedesktop.PackageKit.StateHasChanged posttrans > /dev/null'
```

Seems pretty straightforward. Let's first confirm this is the issue. I made a backup of the file and deleted it. No more error. Ok, so what is PackageKit?

https://www.freedesktop.org/software/PackageKit/pk-intro.html

> Formally, PackageKit is a D-Bus abstraction layer that allows the session user to manage packages in a secure way using a cross-distro, cross-architecture API. 

Nifty. I probably don't want to remove it. Let's reinstall it. Maybe it's broken.

That put both the file, and the error back. Doesn't seem to be specifically PackageKit related.

What's DBus? I know it's pretty important, but I don't know what it is...

https://www.freedesktop.org/wiki/Software/dbus/

> D-Bus is a message bus system, a simple way for applications to talk to one another. In addition to interprocess communication, D-Bus helps coordinate process lifecycle; it makes it simple and reliable to code a "single instance" application or daemon, and to launch applications and daemons on demand when their services are needed. 

Nice. It's how the different parts of Linux send events to each other. So I can probably safely call this command myself. I'll drop the redirect to /dev/null, and I don't need to pass the command to bash so,

```
gdbus call --system --timeout 30 --dest org.freedesktop.PackageKit --object-path /org/freedesktop/PackageKit --method org.freedesktop.PackageKit.StateHasChanged posttrans

Error connecting: Could not connect: No such file or directory
```

That looks familiar. Let's remove parts until we get down to what is throwing the error:

```
gdbus call --system

Error connecting: Could not connect: No such file or directory
```

Wow. We can't send commands to the system message bus. That sounds...impossible? 

There's also a `--session` bus. That one works. So dbus isn't 100% broken. Wouldn't you know, this is the only hook that calls dbus.

I want a dbus viewer. Where's my system bus, and what's on it? 

```
qdbus --system
```

Well, that's interesting. Seems I have a system bus, and there's a lot of things on it. This text dump is herd to read, can I get a visual?

```
qdbusviewer
```

![Screenshot of QDBusViewer, showing that the posttrans command can be successfully sent to the org.freedesktop.PackageKet's StateHasChanged method on the system bus](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/9ns90zq81f6dwkhbmr1s.png)

Well, I can send the exactly same command though this tool. There's nothing wrong with my system bus. Why can't `gdbus` connect to it? Where does `gdbus` come from?

```
pacman -Qo gdbus

/usr/bin/gdbus is owned by glib2 2.76.4-1
```

Part of glib. I can work with that. Starting at https://gitlab.gnome.org/GNOME/glib/-/blob/e8af76ad250a2bb6d5cb18aec056efbc18fb2fb2/gio/gdbus-tool.c I trace the code until I reach the `Error connecting` message on line 685. Looking us a few lines, it seems I need a unix: socket. Going to ask the task manager what socket the `dbus-daemon` is listening to.

It seems to be `/run/user/1000/at-spi/bus_0`

According to https://gitlab.gnome.org/GNOME/glib/-/blob/main/gio/gdbusaddress.c#L1313, that's my session bus. Maybe the system bus is in the same dir? I know sockets tend to live in `/run/`

Turns out, that's the only file there. Maybe that's why gdbus can't find the system bus socket. But we know there is one somewhere, and that it's working. Time for the big toys

`sudo strace gdbus call --system 2>&1 | tee  out.log`[1](#1)

I love `strace`. It will show you every. single. thing that a program is trying to do and is amazing at hunting down "I can't find x" errors. Looks like we are trying to open a socket at...

```
connect(5, {sa_family=AF_UNIX, sun_path="/home/linuxbrew/.linuxbrew/var/run/dbus/system_bus_socket"}, 110) = -1 ENOENT (No such file or directory)
```

Linuxbrew? That doesn't seem right. Why would something that's a core part of glib be looking for a socket in the homebrew directory?? No big surprise, said socket doesn't exist either.

```
brew list

dbus
```

I have dbus installed via homebrew?? 

```
brew remove dbus`

dbus is required by deno
```
...

```
brew remove deno
brew remove dbus
gdbus call --system

Needs more arguments
```

`sudo strace gdbus call --system 2>&1 | tee  out.log`

Ohhh. There it is, 

```
connect(5, {sa_family=AF_UNIX, sun_path="/run/dbus/system_bus_socket"}, 110) = 0
```

Thank you for reading this far. If you guessed that things now work as expected, with no weird connection errors in package actions, you get a cookie. Hope this helps you troubleshoot weird things in the future, Keep #LearningInPublic!

[<a name=1>1</a>] https://web.archive.org/web/20230325170159/https://www.shellhacks.com/redirect-stderr-to-stdout/