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
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
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.log1
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!
[1] https://web.archive.org/web/20230325170159/https://www.shellhacks.com/redirect-stderr-to-stdout/
Top comments (0)