Win.get_pid() returns Gnome Shell PID

Platform
1

When running win.get_pid() on a Nautilus window, the returned PID is of Gnome Shell. Is there a way to get the PID of Nautilus instead?

Original post text (inaccurate, see https://discourse.gnome.org/t/win-get-pid-returns-gnome-shell-pid/28182/5)

I need to detect if a running app is built with Libadwaita. Currently, this is done through checking if libadwaita-1.so is in the /proc/${win.get_pid()}/maps. However, this approach doesn’t work well, since some app windows are spawned by some other process (eg. Nautilus is spawned by Gnome Shell and Flatpak apps are spawned by bwrap). So the only way to get the actual PID is to either iterate through child process tree to get to the one that actually belongs to the app.

So I have two questions:

  1. Is there a way to check if an app uses libadwaita without messing with /proc or /sys files?
  2. If not, is there an easier way to get children of a process with a given PID? I wasn’t able to find anything related in Gio or GLib.
2

Let’s back up a bit, before we end up deeper into an XY problem.

What are you actually trying to achieve?

3

I am trying to achieve exactly what is described, determining if the app uses LibAdwaita. This is needed for the “Skip LibAdwaita applications” setting in Rounded Window Corners.

4

Your approach should work… On Wayland at least, win.get_pid should be returning the PID of the process that is responsible for opening the window. That is, necessarily, the real process. Not its parent.

So, I don’t quite grok the issue you’re describing. What does it matter if Nautilus was started by GNOME-shell, or through Flatpak, or whatever? The real nautilus binary is the one that’s rendering the window, and so that’s the PID you’ll get back.

I just did a quick test with a flatpak’d app via looking glass. And, indeed, window.get_pid() on my GNOME Text Editor window returned the PID of the gnome-text-editor process. I confirmed that the parent process of this gnome-text-editor process is bwrap, so it is running through Flatpak.

Could you elaborate what exactly you’re seeing win.get_pid() return? Because it should be returning exactly what you want.

5

You’re right, it does work fine for Flatpak apps. However, for Nautilus, it returns the PID of Gnome Shell. I’ll edit my post to be more accurate.

6

Ah, it seemingly only happens to Nautilus. Nautilus is special, because it is also a Flatpak portal implementation. To achieve this, Nautilus actually doesn’t use the normal wayland connection, and instead obtains a dedicated privileged connection. This is called the “service channel”.

It seems that Mutter is unable to resolve the PID of windows that exist on the service channel. Might be worth opening a bug report about this.

My guess of how the bug works is pretty simple. When Nautilus starts, it asks gnome-shell for a privileged Wayland connection over dbus. gnome-shell opens this connection, and then hands over the opened socket to Nautilus. My guess is that Mutter gives you the PID of the process that first opened the socket, which in this case is technically GNOME Shell.

Good news is that there are few clients that open the service channel: xdg-desktop-portal-gnome, and nautilus. So, you can probably get away with hard-coding your extension that these two clients use libadwaita, and call it a day.

Still, open a bug report. I suspect things like gnome-shell’s Flatpak-detection are broken by this. So it should be investigated

1 Like