Discord fails to restart for update

[cerulis64]

When the user taps the button at the top right of Discord to update, the application fails to restart, and stays closed. The user then has to manually start Discord again.

[refi64]

Is it reliably reproducible? I've used the button a few times and haven't had that happen, but haven't used it for the most recent update or two...

[cerulis64]

It seems to be happening quite reliably on the updates for me.

Checking the problem reporting application, the "reason" listed is: DiscordCanary killed by SIGTRAP,
and the last log message is: [Modules] Relaunching to install module updates...

Distribution: Fedora 33 (Workstation Edition)
Kernel: 5.10.14-200.fc33.x86_64
Flatpak: 1.10.1
Systemd: 246 (v246.10-1.fc33)
Bubblewrap: 0.4.1

I'll try to reproduce this in a Silverblue VM when I have some time.

[cerulis64]

I was able to reproduce the issue in a VM with the latest version of Silverblue.

[ghost]

I have this issue as well, if I am in the client and click the green "update" button in the top right, my client will exit and not restart itself to begin the update without me manually starting it. This has happened across different distros.

[refi64]

This is weird, I can't reproduce it at all having tried multiple times..

Any chance someone could start it from the CLI, leave the terminal open, then check what it says inside when a restart fails?

[cerulis64]

Here are the last 10 lines:

[Modules] Streaming discord_game_utils@17 to /home/cerulis/.var/app/com.discordapp.DiscordCanary/config/discordcanary/0.0.119/modules/pending/discord_game_utils-17.zip: 92%
[Modules] Streaming discord_game_utils@17 to /home/cerulis/.var/app/com.discordapp.DiscordCanary/config/discordcanary/0.0.119/modules/pending/discord_game_utils-17.zip: 94%
[Modules] Streaming discord_game_utils@17 to /home/cerulis/.var/app/com.discordapp.DiscordCanary/config/discordcanary/0.0.119/modules/pending/discord_game_utils-17.zip: 96%
[Modules] Streaming discord_game_utils@17 to /home/cerulis/.var/app/com.discordapp.DiscordCanary/config/discordcanary/0.0.119/modules/pending/discord_game_utils-17.zip: 98%
[Modules] Streaming discord_game_utils@17 to /home/cerulis/.var/app/com.discordapp.DiscordCanary/config/discordcanary/0.0.119/modules/pending/discord_game_utils-17.zip: 100%
[Modules] Fetching discord_rpc@17 from https://discord.com/api/modules/canary/discord_rpc/17
[Modules] Streaming discord_rpc@17 to /home/cerulis/.var/app/com.discordapp.DiscordCanary/config/discordcanary/0.0.119/modules/pending/discord_rpc-17.zip
[Modules] Streaming discord_rpc@17 to /home/cerulis/.var/app/com.discordapp.DiscordCanary/config/discordcanary/0.0.119/modules/pending/discord_rpc-17.zip: 100%
[Modules] Finished module downloads. [success: 7] [failure: 0]
[Modules] Relaunching to install module updates...

After [Modules] Relaunching to install module updates... it simply exits. According to the shell, it even exited with an exit code of 0.
[Modules] Relaunching to install module updates... only shows up after the green "download" button on the top right of the Discord GUI meant for restarting the client for an update is clicked.

[rowbawts]

This also happens to me every time with the Stable Flatpak on Silverblue.

[CorruptComputer]

Yeah, having this same issue on Fedora 36. The app is killed by SIGTRAP when trying to use the built-in restart for update, however manually closing and restarting the app works fine.

[MiguelSanzBr]

how fix this in fedora too?
canary","sentry":{"environment":"canary","release":"0.0.559"},"wm":"KDE,unknown","nativeBuildNumber":"null"}}
18:32:04.106 › Splash.updateCountdownSeconds: undefined
18:32:04.689 › Initializing voice engine with audio subsystem: standard
18:32:05.106 › Splash.updateCountdownSeconds: undefined
18:32:06.106 › Splash.updateCountdownSeconds: undefined
[WebContents] double crashed (reason: crashed, exitCode: 139)... RIP =(
blackbox: 1/13/2025, 6:32:06 PM GMT-3 14 ❌ render-process-gone { reason: 'crashed', exitCode: 139 }
blackbox: 1/13/2025, 6:32:06 PM GMT-3 15 before-quit
2025/01/13 18:32:06 socat[3] W exiting on signal 15