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

Zwift crashing at startup with "GameMode ERROR: Could not connect to bus:" #154

Open
5 tasks done
gmodena opened this issue Aug 21, 2024 · 17 comments
Open
5 tasks done

Comments

@gmodena
Copy link

gmodena commented Aug 21, 2024

Checklist

  • I have given details of my install including Distribution, Wayland/ XOrg, Parameters Used, echo $XAUTHORITY, etc.
  • I have provided logs showing any errors, if available (use DEBUG=1 zwift)
  • I have filled out the issue template to the best of my ability.
  • This issue only contains 1 issue (if you have multiple issues, open one issue for each issue).
  • This issue is not a duplicate issue of previous issue.

Describe the issue

When running a container (latest tag), Zwift will crash after briefly displaying a window with its logo. The process fails with the following error:

GameMode ERROR: Could not connect to bus: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
dbus[219]: arguments to dbus_connection_unref() were incorrect, assertion "connection != NULL" failed in file ../../../dbus/dbus-connection.c line 2832.
This is normally a bug in some application using the D-Bus library.

Distribution Details

Runtime

  • distro: I'm running on NixOS 24.05.
  • I'm using Wayland.
  • variables CONTAINER_TOOL=docker WINE_EXPERIMENTAL_WAYLAND=1.
  • echo $XAUTHORITY returns /run/user/1000/.mutter-Xwaylandauth.4IZNS2.

Debug log

The following output has been generated by running zwift with DEBUG=1:

+ [[ -f /home/gmodena/.config/zwift/config ]]
+ [[ -f /home/gmodena/.config/zwift/gmodena-config ]]
+ [[ ! -z '' ]]
+ WINDOW_MANAGER=Other
+ IMAGE=docker.io/netbrain/zwift
+ VERSION=latest
+ NETWORKING=bridge
++ id -u
+ ZWIFT_UID=1000
++ id -g
+ ZWIFT_GID=100
+ '[' '!' docker ']'
+ '[' docker == podman ']'
+ LOCAL_UID=1000
+ CONTAINER_UID=1000
+ CONTAINER_GID=100
+ case "$XDG_SESSION_TYPE" in
+ WINDOW_MANAGER=Wayland
+ '[' Wayland = Wayland ']'
+ '[' -z 1 ']'
+ WINDOW_MANAGER=Wayland
++ id -u
+ '[' 1000 -ne 1000 ']'
+ [[ ! -n '' ]]
++ curl -s https://raw.githubusercontent.com/netbrain/zwift/master/zwift.sh
++ sha256sum
++ awk '{print $1}'
+ REMOTE_SUM=732988328e5b86a1174a828a9915f225b024b235d625867a8d2fc092dc09b76f
++ sha256sum .local/bin/zwift
++ awk '{print $1}'
+ THIS_SUM=732988328e5b86a1174a828a9915f225b024b235d625867a8d2fc092dc09b76f
+ '[' 732988328e5b86a1174a828a9915f225b024b235d625867a8d2fc092dc09b76f = 732988328e5b86a1174a828a9915f225b024b235d625867a8d2fc092dc09b76f ']'
+ echo 'You are running latest zwift.sh 👏'
You are running latest zwift.sh 👏
+ [[ ! -n '' ]]
+ docker pull docker.io/netbrain/zwift:latest
latest: Pulling from netbrain/zwift
Digest: sha256:b132af52c6e05c43007c6233dd5145e853e9f4e01c7bbca6f990f79339bf918a
Status: Image is up to date for netbrain/zwift:latest
docker.io/netbrain/zwift:latest
+ GENERAL_FLAGS=(-d --rm --privileged --network $NETWORKING --name zwift-$USER --security-opt label=disable --hostname $HOSTNAME -e DISPLAY=$DISPLAY -e ZWIFT_UID=$CONTAINER_UID -e ZWIFT_GID=$CONTAINER_GID -e PULSE_SERVER=/run/user/$CONTAINER_UID/pulse/native -v zwift-$USER:/home/user/.wine/drive_c/users/user/Documents/Zwift -v /run/user/$LOCAL_UID/pulse:/run/user/$CONTAINER_UID/pulse)
+ [[ -f /proc/driver/nvidia/version ]]
+ VGA_DEVICE_FLAG=--device=/dev/dri:/dev/dri
+ [[ -n unix:path=/run/user/1000/bus,guid=5889ad23b80c43accb1a037066c65c37 ]]
+ [[ unix:path=/run/user/1000/bus,guid=5889ad23b80c43accb1a037066c65c37 =~ ^unix:path=([^,]+) ]]
+ DBUS_UNIX_SOCKET=/run/user/1000/bus
+ [[ -n /run/user/1000/bus ]]
+ DBUS_CONFIG_FLAGS=(-e DBUS_SESSION_BUS_ADDRESS=$(echo $DBUS_SESSION_BUS_ADDRESS | sed 's/'$LOCAL_UID'/'$CONTAINER_UID'/') -v $DBUS_UNIX_SOCKET:$(echo $DBUS_UNIX_SOCKET | sed 's/'$LOCAL_UID'/'$CONTAINER_UID'/'))
++ echo unix:path=/run/user/1000/bus,guid=5889ad23b80c43accb1a037066c65c37
++ sed s/1000/1000/
++ echo /run/user/1000/bus
++ sed s/1000/1000/
+ '[' Wayland == Wayland ']'
+ WM_FLAGS=(-e WINE_EXPERIMENTAL_WAYLAND=1 -e XDG_RUNTIME_DIR=/run/user/$CONTAINER_UID -e $WAYLAND_DISPLAY=$WAYLAND_DISPLAY -v $XDG_RUNTIME_DIR/$WAYLAND_DISPLAY:$(echo $XDG_RUNTIME_DIR | sed 's/'$LOCAL_UID'/'$CONTAINER_UID'/')/$WAYLAND_DISPLAY)
++ echo /run/user/1000
++ sed s/1000/1000/
+ '[' Wayland == XWayland ']'
+ '[' Wayland == XOrg ']'
+ '[' Wayland == XOrg ']'
+ '[' docker == podman ']'
++ docker run -d --rm --privileged --network bridge --name zwift-gmodena --security-opt label=disable --hostname framework-nixos-1 -e DISPLAY=:0 -e ZWIFT_UID=1000 -e ZWIFT_GID=100 -e PULSE_SERVER=/run/user/1000/pulse/native -v zwift-gmodena:/home/user/.wine/drive_c/users/user/Documents/Zwift -v /run/user/1000/pulse:/run/user/1000/pulse --device=/dev/dri:/dev/dri -e DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus,guid=5889ad23b80c43accb1a037066c65c37 -v /run/user/1000/bus:/run/user/1000/bus -e WINE_EXPERIMENTAL_WAYLAND=1 -e XDG_RUNTIME_DIR=/run/user/1000 -e wayland-0=wayland-0 -v /run/user/1000/wayland-0:/run/user/1000/wayland-0 docker.io/netbrain/zwift:latest
+ CONTAINER=a0851f7b937ecfae8b44778f44cfd10c843145ac941929cccbf5b893c3d1079b
+ '[' 0 -ne 0 ']'
++ command -v xhost
+ '[' -x /nix/store/h6i9ar169n5p4795dsp6r04kng73y7ar-xhost-1.0.9/bin/xhost ']'
++ id -u
+ '[' 1000 -ne 1000 ']'

Reproduction steps

  1. The latest version of the script is installed under .local/bin/zwift, with a config similar to the one described in NixOS zwift.nix configuration with home-manager #38
  2. CONTAINER_TOOL=docker WINE_EXPERIMENTAL_WAYLAND=1 .local/bin/zwift
  3. After a while, the Zwift logo appears and the container crashes.
@netbrain
Copy link
Owner

netbrain commented Aug 22, 2024

EDIT: nevermind. seems I linked to old code, xdg-screensaver has been replaced by gamemode.


Maybe caused by the screensaver inhibitor?


[[ -n "${DBUS_SESSION_BUS_ADDRESS}" ]] && while true; do sleep 30; xdg-screensaver reset; done &

Could you try to run the container interactively and change the run_script.sh file manually and run it to see if it changes anything?

Basically if you run DEBUG=1 zwift.sh you should see a line like the following in the log:


docker run -d --rm --privileged --network bridge --name zwift-netbrain --security-opt label=disable --hostname netwrk -e DISPLAY=:0 -e ZWIFT_UID=1000 -e ZWIFT_GID=1000 -e PULSE_SERVER=/run/user/1000/pulse/native -v zwift-netbrain:/home/user/.wine/drive_c/users/user/Documents/Zwift -v /run/user/1000/pulse:/run/user/1000/pulse --env-file /home/netbrain/.config/zwift/config -e DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus -v /run/user/1000/bus:/run/user/1000/bus -e WINE_EXPERIMENTAL_WAYLAND=1 -e XDG_RUNTIME_DIR=/run/user/1000 -e wayland-1=wayland-1 -v /run/user/1000/wayland-1:/run/user/1000/wayland-1 docker.io/netbrain/zwift:latest

And then simply change the -d flag to -it and add --entrypoint bash

You will also have to add vim, or your favorite editor in the container, so execute apt-get update && apt-get -y install vim

and finally edit the /usr/bin/run_zwift.sh file and run the entrypoint.sh script from within the container.

Hope this helps.

@netbrain
Copy link
Owner

You could also just try removing -e DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus,guid=5889ad23b80c43accb1a037066c65c37

@netbrain
Copy link
Owner

I can only suspect that gamemode has some dbus integration that isn't working on your system, try removing the DBUS_SESSION_BUS_ADDRESS environment variables as mentioned.

@gmodena
Copy link
Author

gmodena commented Aug 22, 2024

hey @netbrain . Thanks for the quick reply.

I tried removing DBUS_SESSION_BUS_ADDRESS, but this resulted in the same GameMode error.

@netbrain
Copy link
Owner

Maybe try to remove gamemode altogether?

@gmodena
Copy link
Author

gmodena commented Aug 22, 2024

@netbrain I did try to remove gamemode and re-build the image with the bin/build-image.sh script. The image built, but it reported this error/warning:

0050:err:winediag:nodrv_CreateWindow Application tried to create a window, but no driver could be loaded.
0050:err:winediag:nodrv_CreateWindow L"The explorer process failed to start."
0050:err:systray:initialize_systray Could not create tray window
0024:err:winediag:nodrv_CreateWindow Application tried to create a window, but no driver could be loaded.
0024:err:winediag:nodrv_CreateWindow L"Make sure that your X server is running and that $DISPLAY is set correctly."
------------------------------------------------------
warning: Note: command wine NetFx64.exe /q /c:install.exe /q returned status 43. Aborting.
------------------------------------------------------

When I run the container ($ CONTAINER_TOOL=docker WINE_EXPERIMENTAL_WAYLAND=1 DONT_PULL=1 .local/bin/zwift ) it now fails with that error too. Looks like wine is not starting properly?

I need to check what's up inside the container. I'll f/up here if I have more useful info.

@netbrain
Copy link
Owner

Just change the contents of the container interactively, no need to build. See my steps here

#154 (comment)

@gmodena
Copy link
Author

gmodena commented Aug 22, 2024

Just change the contents of the container interactively, no need to build. See my steps here

Ah! Actually, if I run /usr/bin/entrypoint interactively, zwift successfully starts (without dying) regardless of the gamemode dbus failure.

I tried with and without commenting out the relevant line in run_zwift.sh, and zwift starts either way.

I wonder if the container in daemon mode dies just because entrypoint returns an error. This is after the gamemode crash:

# echo $?
134

However, it looks like dbus is not working in general though, not just for gamemode. From inside the container (and /run/user mounted):

$ dbus-monitor --session
Failed to open connection to session bus: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.

Might be something on my end.

@gmodena
Copy link
Author

gmodena commented Aug 23, 2024

Might be something on my end.

FWIW: I tried starting a dbus session inside the container, before running entrypoint, and with that gamemode does not crash. So it looks like the issue is with shared socket between the container and my host.

@netbrain many thanks for the help troubleshooting this. Do feel free to close the issue if you think it's not relevant (apologies for the noise, in case).

@netbrain
Copy link
Owner

@perrin4869 any idea what could be causing this issue? is it a one-off or is this an actual issue other can experience?

@perrin4869
Copy link
Contributor

sounds like dbus is not setup correctly?
in my system I run

if [[ -z "$DBUS_SESSION_BUS_ADDRESS" ]]; then
  export $(dbus-launch --exit-with-x11)
fi

inside .xprofile (which I run from .xinitrc via . ~/.xprofile) to start the session bus, I think @gmodena would need to figure out how dbus is being started in his system and figure out why he can't connect to the session bus. This could affect other functionality in his system. Or maybe dbus daemon crashed? You could check if dbus is running?

@gmodena
Copy link
Author

gmodena commented Aug 25, 2024

hey @perrin4869 .

Or maybe dbus daemon crashed? You could check if dbus is running?

On the host, I start dbus with systemd (both system and user sessions) and it seems to be working ok. I can access (read/write) the socket $DBUS_SESSION_BUS_ADDRESS from my user's Gnome session. So do all the services running in the wayland/Gnome session.

However, I can't connect from the zwift docker container using that socket. uid/gid and permissions seem match the host.

There's no dbus (host) daemon crash before/while/after the docker container is running.

@perrin4869
Copy link
Contributor

Out of curiosity, could you try from podman? I personally don't use docker and I never tested it.
One possible solution is to add a check for dbus connectivity, and only call gamemode if dbus connectivity has been confirmed.
It also sounds like a bug in gamemode, they should probably handle dbus failures without crashing?

@gmodena
Copy link
Author

gmodena commented Aug 25, 2024

@perrin4869 I did a couple of tests with podman
The app works if I run the container with:

CONTAINER_TOOL=podman  DEBUG=1 .local/bin/zwift

Hurray!

I tested dbus manually (dbus-monitor --session & c) and everything works as expected.

However, wine fails to start if I enable WINE_EXPERIMENTAL_WAYLAND:

CONTAINER_TOOL=podman WINE_EXPERIMENTAL_WAYLAND=1 DEBUG=1 .local/bin/zwift

The failure mode this time is different:

018c:err:combase:RoGetActivationFactory Failed to find library for L"Windows.Foundation.Diagnostics.AsyncCausalityTracer"
01fc:err:winediag:nodrv_CreateWindow Application tried to create a window, but no driver could be loaded.
01fc:err:winediag:nodrv_CreateWindow L"The explorer process failed to start."
018c:err:winediag:nodrv_CreateWindow Application tried to create a window, but no driver could be loaded.
018c:err:winediag:nodrv_CreateWindow L"The explorer process failed to start."
01dc:err:winediag:nodrv_CreateWindow Application tried to create a window, but no driver could be loaded.
01dc:err:winediag:nodrv_CreateWindow L"The explorer process failed to start."
+ pgrep -f ZwiftApp.exe
+ echo 'Killing uneccesary applications'
Killing uneccesary applications
+ pkill ZwiftLauncher

One possible solution is to add a check for dbus connectivity, and only call gamemode if dbus connectivity has been confirmed.

Sounds good. If connectivity is available, the (host) daemon should ack a ping:

$ dbus-send --session --dest=org.freedesktop.DBus --type=method_call --print-reply /org/freedesktop/DBus org.freedesktop.DBus.Peer.Ping

Is GameMode the only component affected by lack of connectivity with the host?

It's weird that this issue only manifests with docker though. I still wonder if there's something messed up with my host.

It also sounds like a bug in gamemode, they should probably handle dbus failures without crashing?

I'm not familiar with gamemode, but yeah. It'd be nice if the lack of dbus access would be handled gracefully.

@netbrain
Copy link
Owner

I'm not familiar with gamemode, but yeah. It'd be nice if the lack of dbus access would be handled gracefully.

I second this. 👍😅

@perrin4869
Copy link
Contributor

gamemode is the only program accessing dbus, so adding the check would solve the issue. Maybe this can be solved upstream in the meantime though, might be worth opening an issue in the gamemode repo to request that it doesn't crash 😅
but yeah, if podman works and docker doesn't, it's most likely some permissions issue... podman has this userns flag which solves a lot of these problems. I think it's worth considering adding a note in the README recommending podman over docker, I know from personal experience the first time I tried running this repo I also tried to start with docker but ran into issues, then a few days later was surprised to find everything was smooth with podman

I never ran wayland yet, don't know about the last podman error ^^;;

@perrin4869
Copy link
Contributor

perrin4869 commented Aug 26, 2024

oh, just looking into gamemode I found this commit: FeralInteractive/gamemode@3fa4189

@netbrain I think updating to the latest 1.8.2 gamemode in the image will fix this issue

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

3 participants