I’ve had this happen twice since upgrading from 24.04 to 26.04. To be clear, the symptoms were as described by Mihail in comment #12 above (and not whatever the OP reported):
loka 25 17:39:30 saegusa systemd[1]: Starting user@60579.service – User Manager for UID 60579…
loka 25 17:39:30 saegusa (systemd)[2446]: user@60579.service: Failed to determine credentials for user ’60579’: Unknown user
loka 25 17:39:30 saegusa (systemd)[2446]: user@60579.service: Failed at step USER spawning /usr/lib/systemd/systemd: Invalid argument
loka 25 17:39:30 saegusa systemd[1]: user@60579.service: Main process exited, code=exited, status=217/USER
loka 25 17:39:30 saegusa systemd[1]: user@60579.service: Failed with result ’exit-code’.
loka 25 17:39:30 saegusa systemd[1]: Failed to start user@60579.service – User Manager for UID 60579.
loka 25 17:39:30 saegusa systemd[1]: Started session-c1.scope – Session c1 of User gdm-greeter.
loka 25 17:39:30 saegusa systemd[1]: Started apache2.service – The Apache HTTP Server.
loka 25 17:39:30 saegusa /usr/libexec/gdm-wayland-session[2491]: dbus[2491]: Unable to set up transient service directory: XDG_RUNTIME_DIR ”/run/user/60579” is owned by uid 60579, not our uid 60578
loka 25 17:39:30 saegusa /usr/libexec/gdm-wayland-session[2491]: dbus-daemon[2491]: [session uid=60578 pid=2491 pidfd=5] Cannot set up inotify for ’/run/gdm3/home/gdm-greeter/.local/share/dbus-1/services’: Permission denied
The first time it happened during a normal reboot, and resolved itself after I rebooted again (using ssh to log in from another system). The second time (last night, as logged above) it happened after a reboot due to VLC causing an unrelated Xwayland crash, and no amount of rebooting ever fixed it.
I stopped nscd (`systemctl stop nscd; nscd -i passwd; nscd -i group`), after which restarting GDM (`systemctl restart gdm`) finally brought the login screen back. I then disabled nscd (`systemctl disable nscd`) to make sure it won’t mess things up again on the next reboot.
The suggestion to stop nscd came from ChatGPT, which apparently based it on a reply to an Ask Ubuntu thread about the same issue [1]. I don’t know what unwanted consequences disabling nscd potentially has, but at least I have a working desktop for now.
* [1] https://askubuntu.com/a/1570171
What Operating System(s) are you seeing this problem on?
Linux Wayland
Which Wayland compositor or X11 Window manager(s) are you using?
Gnome
WezTerm version
20220927-071112-9be05951
Did you try the latest nightly build to see if the issue is better (or worse!) than your current version?
Yes, and I updated the version box above to show the version of the nightly that I tried
Describe the bug
I’m running a standard Ubuntu 20.04 Gnome desktop, but with Wayland. Resizing of wezterm window is broken on this setup: selecting ”maximize” from the title bar context menu or dragging the window against the top or the sides of the screen doesn’t maximize/tile the window, but any resizing that does happen results in any text entered in the terminal thereafter to be get garbled. In this screenshot I’ve first entered wezterm --version before resizing, then dragged the window against the top, then entered wezterm --version again:

To Reproduce
- Install your bog-standard Ubuntu 20.04 desktop in a VM and boot it up.
- On the GDM login screen select ”Ubuntu on Wayland” from the bottom right menu, then log in.
- Install wezterm.
- Start wezterm.
- Right-click wezterm’s title bar and select ”Maximize”.
- Type something
Configuration
no config
Expected Behavior
After step 5, I expect the window to be maximized (i.e. to fill the desktop). After step 6, I expect to see what I typed.
Logs
no logs available
Anything else?
The issue is not present in an X11 session. Ubuntu 20.04 defaults to X11, but I’ve used it with Wayland exclusively since the release without issues. More specifically, I can’t remember seeing resizing issues similar to this with any other application.
I also have a laptop running Ubuntu 22.04 and Wayland, and there all resizing of the wezterm window works just as I’d expect (i.e. just as in any other application).
According to upstream this has been fixed in Gnome 3.0.
As I reported on Launchpad: https://bugs.launchpad.net/ubuntu/+source/gdm/+bug/524497
There’s a usability issue with the login screen’s panel being at the bottom of the screen. It should be at the top, or at the very least the elements that are present in both the login screen and the desktop (the clock and shutdown menu) should be positioned consistently. It’s very confusing as it stands, with the clock and the shutdown function jumping from the bottom of the login screen to the top of the desktop screen when we log in.
Either the top of the screen is the accessibility-wise better place for these elements, in which case they should be there *during the login screen also*, or it isn’t, in which case they shouldn’t be there when we get to the desktop *either*. They shouldn’t be in one place on one screen, in another place on another screen.
Do you know of a way to move the elements around on the login screen? Specifically I’d like to move the bottom panel to the top.
I’ve actually reported this as a bug on Launchpad (https://bugs.launchpad.net/ubuntu/+source/gdm/+bug/524497#) and even tried fiddling with the greeter’s source code myself, but it was just useless guesswork with my non-existent GTK knowledge.