Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Upgrading from 1.2.6 to 1.3.0 causes greetd's regreet to stall for 20-30 seconds #163

Closed
zeyadtamimi opened this issue Jan 6, 2024 · 6 comments

Comments

@zeyadtamimi
Copy link

Hey,

After a recent upgrade I noticed that on when my greeter starts ( ReGreet ) there is a solid 20-35 seconds where I get a blank desktop with a cursor but no actual greeter.

The configuration that hyprland starts with is relatively straight forward:

misc {
    disable_hyprland_logo = true
}

animations {
    enabled = false
}

exec-once = regreet --config /etc/regreet/config.toml; hyprctl dispatch exit

Interestingly, Hyprland seems to start and is fully responsive but the greeter execution is heavily delayed. If I add a binding to start a terminal to the above config then I can immediately start one while waiting for the greeter to actually start.

I decided to look at the journal logs and through several runs I noticed the same pattern. Here I exit out of my hyprland session around 9:13:00 which is when the greeter user takes over. However, the actual greeter screen does no show up on screen until about 9:13:27:

log.txt

21:13:24 xdg-desktop-por[3573]: Failed to create global_shortcuts proxy: Error calling StartServiceByName for org.freedesktop.impl.portal.desktop.hyprland: Timeout was reached
21:13:24 xdg-desktop-por[3573]: No skeleton to export

Through all of the runs the only consistent thing I could see is xdg-desktop-portal-hyprland seems to be timing out on something. I tried replacing it with xdg-desktop-portal-wlr and the problem goes away, no more timeout message and no more delays with greeter start. Downgrading from 1.3.0 to 1.2.6 also seems to fix the issue.

Any help here would greatly be appreciated.

@vaxerski
Copy link
Member

vaxerski commented Jan 6, 2024

usually means xdph is crashing. Check systemctl --user status xdg-desktop-portal-hyprland

@zeyadtamimi
Copy link
Author

In the that half a min window between hyprland starting and the greeter starting I managed managed to execute systemctl --user status xdg-desktop-portal-hyprland as the greeter user:

× xdg-desktop-portal-hyprland.service - Portal service (Hyprland implementation)
     Loaded: loaded (/usr/lib/systemd/user/xdg-desktop-portal-hyprland.service; static)
     Active: failed (Result: core-dump) since Sat 2024-01-06 08:40:29 PST; 23s ago
    Process: 1028 ExecStart=/usr/lib/xdg-desktop-portal-hyprland (code=dumped, signal=ABRT)
   Main PID: 1028 (code=dumped, signal=ABRT)
        CPU: 4ms

Unfortunately, it seems not much is being recorded other than the SIGABRT.

@zeyadtamimi
Copy link
Author

Managed to get one of the cores analyzed:

#8  0x0000564df76a9734 in CPortalManager::CPortalManager (this=0x564df828a2e0)
    at /usr/src/debug/xdg-desktop-portal-hyprland/xdg-desktop-portal-hyprland-1.3.1/src/core/PortalManager.cpp:207

Which corresponds to: throw "$HOME and $XDG_CONFIG_HOME both missing from env";

I see, and that code was added since 1.2.6 which would explain why the crash is happening in 1.3.0: c5b69eb

Am I correct in my interpretation that this means that greetd is not setting up all the "normal" environmental variables for the greeter user?

Is xdph for a greeter? Can I just somehow disable it for the greeter user?

Examining the code I also see that xdph is tolerant of it's config file being missing .allowMissingConfig = true but is not tolerant of the home directories not existing. Is this intentional?

@vaxerski
Copy link
Member

vaxerski commented Jan 6, 2024

xdph should be ran as your user,

yes, it allows a missing config, I guess we can handle that case. Ping me tomorrow, I'll fix this.

Thanks for analyzing the dump

@zeyadtamimi
Copy link
Author

Hey @vaxerski ,

Thanks for agreeing to change the behavior!

xdph should be ran as your user: Is there a way to disable XDPH or XDP in for system users like the greeter user? Or will it always try to run when Hyrpland starts up?

@vaxerski
Copy link
Member

vaxerski commented Jan 7, 2024

it should be governed by sysd, idk

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants