Closed itaranto closed 3 years ago
Which version if xdpw is this?
Looks like the first time it connects to Wayland successfully but output manager protocol versions aren't available.
22:02:16 [ERROR] - Compositor doesn't support zxdg_output_manager_v1!
All subsequent launches fail to connect to wayland.
Could you also share your relevant greetd configs? Specifically what compositor you have it launching and its configs? I'm guessing you are using greetd with cage?
Which version if xdpw is this?
0.4.0-2
according to pacman
Looks like the first time it connects to Wayland successfully but output manager protocol versions aren't available.
22:02:16 [ERROR] - Compositor doesn't support zxdg_output_manager_v1!
All subsequent launches fail to connect to wayland.
Could you also share your relevant greetd configs? Specifically what compositor you have it launching and its configs? I'm guessing you are using greetd with cage?
No, I'm using greetd-gtkgreet
with Sway itself, here's my greetd config:
https://gitlab.com/itaranto/dotfiles/-/tree/master/sys/etc/greetd
And this is how I launch the "real" Sway session from greetd: https://gitlab.com/itaranto/dotfiles/-/blob/master/sys/usr/local/bin/start-sway
Can you post the contents of any files in /etc/sway/config.d/*
? I'm looking for some form of environment variable syncing with systemd or dbus. My guess is WAYLAND_DISPLAY
not being properly set in your greetd seay session.
Can you post the contents of any files in
/etc/sway/config.d/*
? I'm looking for some form of environment variable syncing with systemd or dbus. My guess isWAYLAND_DISPLAY
not being properly set in your greetd seay session.
There's only this file: /etc/sway/config.d/50-systemd-user.conf
, provided by the Arch Linux's package:
# sway does not set DISPLAY/WAYLAND_DISPLAY in the systemd user environment
# See FS#63021
# Adapted from xorg's 50-systemd-user.sh, which achieves a similar goal.
exec systemctl --user import-environment DISPLAY WAYLAND_DISPLAY SWAYSOCK
exec hash dbus-update-activation-environment 2>/dev/null && \
dbus-update-activation-environment --systemd DISPLAY WAYLAND_DISPLAY SWAYSOCK
I'm including /etc/sway/config.d/*
both in my greetd Sway config as well as my user Sway config.
In case I didn't mention it before, both Sway sessions work just fine, it's just that greetd takes around 30 seconds to start due to xdpw crashing.
There's only this file:
/etc/sway/config.d/50-systemd-user.conf
, provided by the Arch Linux's package
I was hoping this wasn't there. My guess was that xdpw couldn't connect to wayland because it couldn't see the WAYLAND_DISPLAY
environment variable. This included config helps to ensure that sway propagates its environment to d-bus/systemd.
In case I didn't mention it before, both Sway sessions work just fine, it's just that greetd takes around 30 seconds to start due to xdpw crashing.
Yep, makes sense. Does xdpw crash in your full sway instance as well?
How are you getting a debug log from xdpw inside the sway session that gtkgreet lives in, btw? I don't see any provision for that in your config.
Edit: nevermind, journalctl.
Try this for me and let me know what happens...
https://gitlab.com/itaranto/dotfiles/-/blob/master/sys/etc/greetd/config.toml#L5
Just as a test, change that line to:
command = "XDG_CURRENT_DESKTOP=sway sway --config /etc/greetd/sway-config"
I think your logs might indicate an issue with your full sway session and not your greetd session, but I could be wildly off base. If I'm right, you have two problems, both easily solved.
Yep, makes sense. Does xdpw crash in your full sway instance as well?
Nope, it works fine. I can do video-conferencing in Sway without any issue.
How are you getting a debug log from xdpw inside the sway session that gtkgreet lives in, btw? I don't see any provision for that in your config.
Edit: nevermind, journalctl.
Yes, journalctl. I created a replacement systemd file under /etc/systemd/user/xdg-desktop-portal-wlr.service
with the -l DEBUG
flag to get the debug logs.
Try this for me and let me know what happens...
It didn't work as it is because greetd complained about XDG_CURRENT_DESKTOP=sway
not being a command.
So, what I did was to create a script /usr/local/bin/greetd-sway
containing:
#!/bin/sh
export XDG_SESSION_TYPE=wayland
export XDG_SESSION_DESKTOP=sway
export XDG_CURRENT_DESKTOP=sway
sway --config /etc/greetd/sway-config
And to reference it in /etc/greetd/config.toml
:
[terminal]
vt = 1
[default_session]
command = "greetd-sway"
user = "greeter"
But xdpw kept crashing.
Ugh, that shoots that theory. Any change in the logs?
Ugh, that shoots that theory. Any change in the logs?
It's strange, xdpw is still crashing but now there's no logs.
Another strange thing is that I found a crash for gtkgreet that I can reproduce 100% of the time. Every time I enter an incorrect password it segfaults, with a correct one it doesn't. I'll report that to greetd-gtkgreet
.
I think this is probably unrelated to xdwp.
If you build xdg-desktop-portal-wlr-git from AUR, it'll include debugging symbols and you can send us a backtrace if you're getting a segfault style crash in xdpw.
If you build xdg-desktop-portal-wlr-git from AUR, it'll include debugging symbols and you can send us a backtrace if you're getting a segfault style crash in xdpw.
#0 0x00007feca2906515 in __strlen_avx2 () from /usr/lib/libc.so.6
#1 0x0000561452cf95ca in get_config_path () at ../xdg-desktop-portal-wlr-git/src/core/config.c:109
#2 init_config (config=0x7ffe4fc04eb0, configfile=<synthetic pointer>) at ../xdg-desktop-portal-wlr-git/src/core/config.c:165
#3 main (argc=1, argv=<optimized out>) at ../xdg-desktop-portal-wlr-git/src/core/main.c:84
I took a look at the code and it seems you are calling strlen
over a NULL
pointer, here:
const char *home = getenv("HOME");
size_t size_fallback = 1 + strlen(home) + strlen("/.config");
The environment variable HOME
is not defined because greetd and greetd-gtkgreet run as the greeter
user.
The greeter
user has no home:
[I] ~ $ cat /etc/passwd|grep greeter
greeter:x:976:976:greetd greeter user:/:/bin/bash
Now that I think of, isn't HOME
guaranteed to be always defined?
Let me know if you need anything else.
OK, as an example, I checked the environment variables xdg-deskop-portal
under the greeter
user session and it doesn't contain the HOME
variable.
I used strings /proc/<PID>/environment
to check this.
You nailed it! This is a regression. @columbarius, can we make these getenv
calls safe? If you don't have time, I may be able to push a PR tomorrow evening.
You nailed it! This is a regression. @columbarius, can we make these
getenv
calls safe? If you don't have time, I may be able to push a PR tomorrow evening.
getenv
calls are "safe" by default in that they either return a string or NULL, we just need to check for that.
@itaranto Thanks for finding hat. Never came to my mind, that xdpw could run as a system user without home.
Could you test if #151 fixes it, please?
Looks like this got closed automatically by merging #151. Reopening it for confirmation.
@itaranto Thanks for finding hat. Never came to my mind, that xdpw could run as a system user without home.
That's strange, I'll probably do more research, for example xdg-desktop-portal
has HOME
defined in my regular session but not in the greetd session.
Could you test if #151 fixes it, please?
Yes, I just built xdg-desktop-portal-wlr-git
and it didn't crashed in the greetd's login screen.
I'm using
greetd
as login manager with the GTK greeter and Sway.This setup is more or less explained here and here.
After a specific upgrade, the greeter now takes a few seconds to start due to xdpw crashing and being restarted several times.
Here's the log with
-l DEBUG
: xdpw.logThis is what
coredumpctl info
says: