Score:1

Ubuntu

Slow startup of gnome-terminal as root

raj

1/22/24, 6:59 PM

Could anybody help me debug the following issue: I have a menu shortcut that starts up gnome-terminal as root. The shortcut refers to the following .desktop file:

[Desktop Entry]
Name=Root Terminal
Exec=/usr/local/bin/root-term
Comment=Root Terminal
Terminal=false
Icon=org.gnome.Terminal
Type=Application

The script /usr/local/bin/root-term is basically one command (it didn't work properly when I tried to put the command directly into the .desktop file, hence the separate script):

#!/bin/bash
pkexec env SSH_AUTH_SOCK=$SSH_AUTH_SOCK DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY gnome-terminal

This worked perfectly until now. Since few days, after some update (however I don't know which one) the first time I click this menu shortcut, pkexec's password prompt pops up and after I enter the password I have to wait several seconds until the terminal window appears.

This happens only when the script is run the first time after the machine is booted. On subsequent clicks on this menu item, the terminal window appears instantly after answering the password prompt.

I don't even know where to start looking for. Any ideas? Ubuntu 20.04.

423

2 + 4

root

gnome-terminal

pkexec

20.04

Arjun K Shibu

1/26/24, 7:00 PM

Try `gksudo` instead of `pkexec` also disable the `pkexec.`

0

Reply

raj

1/27/24, 11:08 AM

`gksudo` is not present on my system, even no candidate to install is prompted when I type `gksudo`.

0

Reply

sudodus

1/28/24, 2:23 PM

I simply run `sudo whatevercommand` in a normal `gnome-terminal` window and it works as before also in an up to date version of Ubuntu 22.04.x LTS. I don't see why you want a separate desktop entry for `gnome-terminal` as root.

0

Reply

raj

1/28/24, 6:43 PM

@sudodus Simply a matter of convenience. If I want to do something as root, it's usually something more than just a single command. In that case I just prefer to have a clearly separated terminal window where I can work as root. I'm just used to working that way and I don't see any reason to change the way of working that is convenient and effective for me.

0

Reply

Score:2

Ubuntu

sudodus

1/28/24, 8:55 PM

Desktop file for Root Terminal

The following desktop file works for me (when located in /usr/share/applications/) in current 20.04.x and 22.04.x,

[Desktop Entry]
Version=1.0
Name=Root Terminal
Exec=gnome-terminal --title='Root Terminal' -- sudo -i
Comment=Root Terminal
Terminal=false
Icon=org.gnome.Terminal
Type=Application

You may want to use sudo -iH, but if I understand correctly, -H is no longer necessary to protect graphical applications, that can be run both with and without elevated permissions.

Edit: gvfs admin backend

The gvfs admin backend is a good tool for elevated permissions with GUI tools. In Ubuntu 17.10 (gvfs >= 1.29.4) and newer versions you can use the gvfs admin backend. Notice that you need the full path, for example

thunar admin:///path/to/directory
gedit admin:///path/to/file

In theory, the gvfs admin backend method (which uses polkit) is better and safer (than xhost and sudo -H), regardless of the UI you use.

You don't run the whole application as root. Privilege escalation happens only when strictly necessary.

+ 13

raj

1/28/24, 9:37 PM

While this works, it does not fully solve my problem. The actual problem is some unexplainable delay the first time `pkexec` is started (that previously didn't occur). I want to find the root cause of this problem and solve it, because I have also other similar shortcuts that call some specific programs as root (for example `gedit` to edit a particular file) and your method cannot be used in that case.

0

Reply

sudodus

1/28/24, 10:23 PM

I see. Then I suggest to try the gvfs admin backend with gedit. See the edited answer. I don't know if it works with all the tools that you want to use with pkexec, and I don't know if the gvfs admin backend is affected by the delay ...

0

Reply

raj

1/29/24, 6:06 PM

That still can be considered only a workaround, not a solution. It's better than nothing, but I look for a solution.

0

Reply

sudodus

1/29/24, 6:45 PM

Have you tested in an up to date [persistent] live system (20.04.x LTS and/or 22.04.x LTS) if your desktop files and associated shellscripts work as intended (without a delay)? In that case there is probably something specific in your current operating system, that causes the problem.

0

Reply

raj

1/29/24, 8:41 PM

I already mentioned that this changed after some recent update. Previously it worked without this delay. It is even more strange that this delay happens only with first run of `pkexec`. So definitely something did change in the system and I would like to know what the change is. If all else fails, I guess I'd have to run `pkexec` under `strace` and check if it tells me when exactly (on which function call) is the delay occurring...

0

Reply

sudodus

2/3/24, 8:05 AM

@raj, Sorry that I could not fully solve your problem. You may find someone with good knowledge about `pkexec` via https://ubuntuforums.org or https://discourse.ubuntu.com/

0

Reply

raj

2/22/24, 11:11 PM

I finally got some time to investigate this and `strace` showed that the problem is somewhere within GNOME itself, `pkexec` is not at fault. `gnome-terminal` and `gedit` exhibit identical delay when eg. started for the first time from root shell obtained by `sudo`. `strace` shows timeouts when trying to get data from some service (the pattern is identical with both programs), but I'm unable to analyze it further.

1

Reply

sudodus

2/23/24, 8:16 AM

What happens if you replace `gnome-terminal` and `gedit` with `sakura` and `geany` (or some other non-gnome programs)? Will you get rid of the delay that way?

0

Reply

raj

2/23/24, 1:20 PM

I don't have these programs, but I have one more GUI application that I start as root using `pkexec` method, it is `grsync` (a GUI frontend for `rsync` - I use it for backups). It starts without any delays. So probably for other non-GNOME programs there will be no delays as well.

0

Reply

sudodus

2/23/24, 1:27 PM

Could it be that some component of gnome is located on a bad but not completely failing sector on the drive? In other words, reading that component from the drive might need several re-tries, but once it is read, a copy will be in RAM, so that next time it will be fast.

0

Reply

raj

2/23/24, 4:46 PM

I don't think so, as probably the same components are used regardless if programs are started from root or non-root, and when started as non-root the programs don't exhibit any delay. I have one already running copy of `gnome-terminal` (non-root) and there's delay in starting the root one. And my system drive where OS is installed is a SSD drive, I don't know if anything like "bad sectors" is possible on that kind of drive.

0

Reply

raj

2/23/24, 4:52 PM

It looks like starting the program starts some service that stays up even after the program ends, and the delay comes from starting that service. When I ran the program under `strace`, even after I quit it, something was still attached to `strace` and printing debug messages - I had to Ctrl-C out of it, and when I ran the program next time there was delay again, because probably Ctrl-C interrupted the service. This is reproducible. When I run without `strace`, the service stays up and there's no delay the second time.

0

Reply

sudodus

2/23/24, 9:51 PM

Interesting. There should be a way to find out which program/process it is (that was still attached to strace and printing debug messages). Maybe, if you check with `ps` before and after ctrl-C, you might find something. I am not very good at interpreting log messages, but if you ask at 'Unix & Linux', some guru might get interested and help you find it.

0

Reply

Score:1

Ubuntu

Mdurks

3/29/24, 10:32 PM

Had basically the same issue: (20.04) using pkexec in a .desktop file to open a program that would delay on first launch for ~20 seconds.

In my case, it was caused by a bug with xdg-desktop-portal:
https://bugs.launchpad.net/ubuntu/+source/xdg-desktop-portal/+bug/1878081

Other users have reported it safe to uninstall, which fixed it for me:

sudo apt remove xdg-desktop-portal

+ 3

raj

3/30/24, 9:53 PM

The description of xdg-desktop-portal package says that it is used to allow snap applications eg. open files outside the sandbox. As I use Chromium which is distributed as snap only, I'll probably need it, so won't uninstall it. However, it is probably the root cause as the delay looks very similar to delay when starting snap applications. Thanks for the info and link to the bug!

0

Reply

raj

3/30/24, 10:15 PM

Instead of uninstalling, I managed to find in the net the previous version of the xdg-desktop-portal package, 1.6.0-1ubuntu1 (current one is 1.6.0-1ubuntu2) and downgraded. Can confirm that after downgrade the problem disappeared.

0

Reply

Mdurks

3/31/24, 9:56 PM

Np! Thanks for finding a cleaner solution.

0

Reply