gnome-control-center takes excessively long to open #200
Comments
|
Hey @jamesps-ebi, thanks for reporting this issue. Can you provide me a step-by-step of what you did post installation? I'm trying to reproduce the gnome-control-center problem that you've mentioned, but I'm not able to. In my test environment, the control center is opening normally. |
Sure no problem. Here's a step-by-step of how I set up my test VM:
After the above, I went and configuring AAD logged in with a domain account. |
|
Same issue again with a new VM using the desktop installer image. After configuring AAD and logging in with a domain user, gnome-control-center is taking upwards of 20 seconds to open every time. Adding the systemd journal entries from this attempt as well. |
denisonbarbosa
added
bug
|
Same here on Ubuntu server -> ubuntu-desktop |
|
Same here on ubuntu desktop. Also changing anything in the manage (like dark appearance) does not do anything. |
|
@denisonbarbosa on your most recent version Also, I am unable to collect the diagnostic information:
|
|
@ jamesps-ebi, could you confirm something for me? Did you enable the pam module for creating the home directory? This can be done by running: # enable the mkhomedir module
sudo pam-auth-update --enable mkhomedir
# remove the aad cache (just removing the files in `/var/lib/aad/cache` is enough)
sudo rm /var/lib/aad/cache/*
# try logging in with the aad user again If you didn't, would you mind trying it and providing some feedback on whether the problem still happens? @turowicz, would you mind trying the same thing as well and try switching to dark mode again? |
I don't think I had this enabled. Pretty sure it's disabled by default. In any case, I will test and report back. |
|
I have enabled it in the very beginning as it is in the documentation Readme.MD |
Yes you're right. It's been a little while since I first tested this. I did have mkhomedir enabled last time. @denisonbarbosa I just tested again to be sure and I'm having the same issue. mkhomedir is enabled |
|
Had the same issue, although all apps were slow. I got it fixed but dont know what the issue is: I started with a fresh download of 23.10 desktop in a VM. Do the setup steps: Logout and login as my AAD user. Notice everything is very slow. Reboot. Logged into local account again, and everything was working fine, so it's not a resource issue. I tried disabling security defaults in AAD to get rid of MFA since I was seeing some "interrupted" attempts in the sign-in logs in Azure, but this did not help. Created a fresh non-admin user just to confirm, still slow. Renabled security defaults, created a new testuser, changed /etc/aad.conf. Commented out my homedir = /home/%u (so now its %f as it's the default). Now everything is working just fine on my test user. Login as my main user, still a problem. Delete passwd.db file, login again, still slow but I got the "correct" homedir with my userprincipalname now. Reinstall Ubuntu, do all the setup steps again without setting the homedir in /etc/aad.conf. Login with my main user, still slow. Create new test user, login with that, works fine. So I dont know what is causing it, but I assume it might be because my main user is an administrator in AAD. I'm not about to remove that, it's too late and I don't want to make a mistake and lock myself out. |
|
@jamesps-ebi @denisonbarbosa @lithdk @turowicz could be the same problem like in #441 |
aad-auth assigns users to UIDs which are too large for some common software. There are many reports of this problem, notably relating to xdg-desktop-portal-gnome not working: - In ubuntu#278, screensharing does not work because the portal is not loaded. - We have also had this problem. - In ubuntu#200, applications take excessively long to open. - We have experienced this issue with a variety of apps, including the nmapplet, gnome-terminal, and chromium. - In ubuntu#441 brings up exactly this issue, but hasn't had a response. Adding a `min_uid` and `max_uid` configuration option allows the user to specify the range in which UIDs should be generated, thereby enabling admins to cap the UIDs at a range which works with most software. To prevent existing installations from changing their behaviour, the default values, when the parameters aren't specified in the configuration file, remain at `100000` and `math.MaxUint32`, however the config template now explicitly sets the values to values which play nicely with xdg-desktop-portal-gnome, in an attempt to give new users a better experience. Also, when a collision is found, instead of only incrementing the UID, which may overflow and end up as UID 0 (root!!!), we instead wrap around only within the specified range.
When logged in as an AAD user account, opening the gnome-control-center app takes much longer than expected to open.
For an AAD user, it is taking roughly 25 seconds to open every time.
For a local user on the same machine, it is taking ~1 second.
Following the systemd journal, while attempting to open the app, I can't see any obvious issues, but I'm including the relevant output here:
A wild guess, but I assume this could be related to policy-kit in some way since trying to add network connections via the gnome-control-center also is not possible. The buttons are all greyed-out.
Again, I don't have this problem with a local user account (also non-privileged).
The text was updated successfully, but these errors were encountered: