Downtown Doug Brown

Sometime back in 2018, I tried out a fresh install of Ubuntu MATE 18.04 on one of my computers and noticed a strange problem when I attempted to install Google Chrome. I clicked the little Firefox icon in the top panel:

Then I downloaded the latest Chrome .deb from Google and opened it up from inside of Firefox:

At this point, GDebi popped up giving me the option to install it. Everything seemed totally normal so far.

When I clicked Install Package, the installer window just disappeared. I sat around for a moment thinking maybe it was busy doing something in the background, but nothing ever happened. What I expected to see was a dialog asking me for my password so that the installation could continue with superuser privileges. That was how it worked on 16.04.

To be honest, at the time I just ignored this issue. I didn’t want to deal with it. I went off to the trusty Linux terminal and installed Chrome that way instead:

sudo dpkg -i google-chrome-stable_current_amd64.deb

I got Chrome up and running and put its icon in place of Firefox’s in my panel. Both browsers are great, by the way — I just prefer Chrome.

I thought nothing of it and continued playing around in my new Linux install. A few days later I downloaded another .deb file in Chrome and attempted to install it. The exact same thing happened! The installer went away when I clicked the Install Package button. So the problem wasn’t Firefox-specific. It also affected Chrome, and was likely completely agnostic to my browser choice.

Should I have looked deeper into this problem back then? Probably. This same setup worked fine with 16.04, so something had changed between 16.04 and 18.04. But at that point I just didn’t have the time or motivation to dig deeper. I ignored the problem. It was a minor thing for me since I could just install packages from the command line instead, but I bet it was puzzling for newer users. Throughout the years I tried out newer Ubuntu versions with my same setup using Chrome, and the problem remained. It happened in 20.04 and 22.04, and as of today it’s still happening in 24.04.

Two and a half years ago, I committed to doing more open-source contributions in my free time and was finally irritated enough about this problem to look into it. I searched around for more info. Lo and behold, lots of people were also affected and there was already an issue from 2019 on Ubuntu’s bug tracker about it. Note: the original bug text was everything underneath the “[ Original Description ]” section. The stuff at the top is recent paperwork I filled out for the Stable Release Update (SRU) process.

People had already done some research on the underlying issue by the time I jumped in. In particular, Lantizia, who is the original bug submitter, mentioned that a wrapper script could be created to work around the problem, and also pointed out an error message that was showing up: “Refusing to render service to dead parents.” Alkis Georgopoulos provided a more robust wrapper script solution and also wrote some excellent background information about the problem in 2020.

In summary, the problem was that GDebi was using execv() to replace itself with an instance of pkexec, which was intended to bring up an authentication dialog and then allow GDebi to run as a superuser. pkexec didn’t like this arrangement, because it wants to have a parent process other than init. Alkis mentioned that you could recreate the problematic scenario in a terminal window by running gdebi-gtk with setsid to run it in a new session.

I didn’t do any of the excellent research to figure this all out, but I noticed the bug report was just sitting there idle. Nobody was doing anything about it, even though it was a severe usability issue with the default GUI package installer provided by Ubuntu MATE and Xubuntu, among others I’m sure. Occasionally people would chime in to say it’s not fixed yet, and also sometimes people would say they were no longer seeing the problem anymore. This kind of confused me, but I wanted to get to the bottom of it. I started experimenting and trying to figure out how to fix it in GDebi’s codebase.

I tested various versions of Ubuntu and found that this problem first appeared sometime in 2017. In Ubuntu MATE 17.04, it works fine and this is what the authentication dialog looks like. It dims your entire screen:

On the other hand, in Ubuntu MATE 17.10 the authentication dialog doesn’t show up and GDebi closes. If you can get the dialog to appear using one of the workarounds listed in the bug report, it looks like this instead. Also, it doesn’t take over your whole screen:

If you’re a long-time Linux user this might bring back some fond memories of how the UI used to look. What’s actually going on here is the old authentication screen was provided by gksu and the new authentication screen is provided by pkexec/PolicyKit/polkit. gksu was removed from Debian/Ubuntu around this time, so GDebi needed an update because it was using gksu under the hood. This change is what introduced the problem.

In order to make a patch, I had to figure out where the source code for GDebi actually lived. The code tab on Launchpad didn’t really give me the underlying source repository. It just led me to a Git repo that Ubuntu uses for tracking their own releases. It had the code, but everything was squashed into single commits for each release rather than the actual underlying commits. I noticed there was also a “View Bazaar branches” link, but it looked like it hadn’t been touched since 2015. Somehow clicking through enough links also took me to this Git repo, which also hadn’t been updated since 2015 but looked more like what I was trying to find. Where was the actual original repository with the latest commits since 2015? I knew it had been updated since then.

I guess there isn’t really an active repository anymore. GDebi appears to be abandoned. So Debian and Ubuntu developers have been adding NMUs (non-maintainer uploads) on top of it for years now, including the change to use pkexec that introduced this bug in 2017. So that repository with all of Ubuntu’s squashed commits that I linked above does indeed seem to be the current source of truth for GDebi’s source code. If someone else understands this source code situation better than me, feel free to correct me if I’m wrong!

The actual code fix for this bug was pretty easy, and I submitted it as a merge request back in 2022. My first attempt was a tad bit on the sloppy side. It stuck with using os.execv() to launch pkexec, but it used a newly-created script that would stay alive as the parent process for pkexec. My justification for doing it that way at the time was that I wouldn’t have to worry about any side effects from the existing unprivileged GDebi instance because it would be completely replaced by execv(). During the code review process a year and a half later, this was deemed overcomplicated, so I changed my approach to use subprocess.call() instead. This required hiding the original unprivileged GDebi window because its process would stay alive in the background.

My new approach also worked great. I resubmitted my change, got a response that it would be looked at in a few days, and then I promptly forgot about the whole thing. A year later in June of 2024, I noticed it was still broken in 24.04 and remembered that I had never heard anything more about my submission. This inspired me to write another comment on my merge request, which seemed to finally kickstart the process of releasing my fix. I also wrote up “SRU paperwork” so that the fix can be backported to some earlier LTS releases. This paperwork can be seen as the [ Impact ], [ Test Plan ], [ Where problems could occur ], and [ Other Info ] sections that have been added to the top of the original bug description.

As is commonly the case in software development, the difficult part of this fix had nothing to do with the code itself. All of my effort was spent figuring out Ubuntu’s patch submission processes and advocating for my merge request. Nobody else seemed to be interested in doing the work to actually fix this bug that has been plaguing Ubuntu MATE and Xubuntu, not to mention some Debian users, for over 6 years. After dealing with the long process of getting my merge request approved, I think I’m starting to understand why!

I think there are a number of reasons that the bug lasted this long. First off, it doesn’t affect everyone. This led to a lot of confusion in the original report because people would chime in with conflicting info about how it was still reproducible or no longer occurring. It turns out that it depends on how you launch your browser. In Ubuntu MATE, launching your browser from the top panel causes it to be parented by mate-panel. When Chrome launches gdebi-gtk (which is a Python script), python ends up parented by init (PID 1). On the other hand, if you launch your browser by clicking the Google Chrome icon in the MATE dropdown menu as seen below, the parenting differs.

In that case, Chrome belongs to systemd --user instead. GDebi/python also ends up being parented to systemd, and thus the bug doesn’t happen because pkexec ends up with systemd as a parent too. This perfectly explains why people (including myself) would falsely claim the bug was fixed. It depended on how the browser was being opened!

To further add to the confusion, sometime after 20.04, Ubuntu switched to using a snap for Firefox instead of a “normal” apt package. With the Firefox snap, the bug also doesn’t occur because for some reason, Firefox always ends up launching GDebi as a child of systemd, even if its own parent is mate-panel. If you install Firefox as a deb instead, the problem comes back. Thanks to Alkis for pointing me in the right direction when Firefox started making me question my sanity.

As far as things on Canonical/Ubuntu’s side, after I submitted my fix two and a half years ago, it looks like what happened here is this bug kind of slipped through the cracks because GDebi appears to be unmaintained. Ubuntu’s processes aren’t/weren’t prepared to handle it. Robie Basak apologized and mentioned that some process fixes are in the works for this type of situation.

Yesterday, this fix was finally released for the upcoming Ubuntu 24.10 version. I installed a daily build of 24.10 and confirmed that after fully updating it, the problem is completely gone. As of right now, it sounds like the plan is that in the coming days/weeks/months it will eventually be backported to 22.04 and 24.04 as mentioned in the original issue. I assume 18.04 and 20.04 are too old for backporting a fix at this point. If you are still on one of those older releases for whatever reason, I think Alkis’ workaround should work well, or you could just manually apply my patch to /usr/share/gdebi/GDebi/GDebiGtk.py.

Thank you to all the Canonical developers who helped push this long-overdue bug fix across the finish line! I definitely recognize that this was a weird case to deal with because GDebi seems to have no current maintainer. It will be nice to have a fully-working install button again, especially since GDebi is still the default package installer on several Ubuntu flavors. Most of all, I hope getting this released will help to prevent many new users from experiencing immediate confusion the first time they try installing a .deb package.