signal-desktop
signal-desktop copied to clipboard
snapcrafters
[Bug]: signal-desktop fails to start
What happened?
signal-desktop no longer starts since last update.
What should have happened?
Well, it should start...
Output of snap info $snap_name
$ snap info signal-desktop
name: signal-desktop
summary: Private messaging from your desktop.
publisher: Snapcrafters
store-url: https://snapcraft.io/signal-desktop
contact: https://github.com/snapcrafters/signal-desktop/issues
license: AGPL-3.0-only
description: |
Private messaging from your desktop.
To use the Signal desktop app, Signal must first be installed on your phone.
**Are you having issues?**
Let us know by creating a new issue here: https://github.com/snapcrafters/signal-desktop/issues
**Authors**
This snap is maintained by the Snapcrafters community, and is not necessarily endorsed or
officially maintained by the upstream developers.
commands:
- signal-desktop
snap-id: r4LxMVp7zWramXsJQAKdamxy6TAWlaDD
tracking: latest/stable
refresh-date: yesterday at 13:44 EST
channels:
latest/stable: 5.63.1 2022-11-20 (405) 197MB -
latest/candidate: ^
latest/beta: ^
latest/edge: 5.63.1 2022-11-19 (405) 197MB -
installed: 5.63.1 (405) 197MB -
Output of snap connections $snap_name
$ snap connections signal-desktop
Interface Plug Slot Notes
audio-playback signal-desktop:audio-playback :audio-playback -
audio-record signal-desktop:audio-record :audio-record -
browser-support signal-desktop:browser-support :browser-support -
camera signal-desktop:camera :camera -
content[gnome-42-2204] signal-desktop:gnome-42-2204 gnome-42-2204:gnome-42-2204 -
content[gtk-3-themes] signal-desktop:gtk-3-themes gtk-common-themes:gtk-3-themes -
content[icon-themes] signal-desktop:icon-themes gtk-common-themes:icon-themes -
content[sound-themes] signal-desktop:sound-themes gtk-common-themes:sound-themes -
desktop signal-desktop:desktop :desktop -
desktop-legacy signal-desktop:desktop-legacy :desktop-legacy -
gsettings signal-desktop:gsettings :gsettings -
home signal-desktop:home :home -
network signal-desktop:network :network -
opengl signal-desktop:opengl :opengl -
removable-media signal-desktop:removable-media - -
screen-inhibit-control signal-desktop:screen-inhibit-control :screen-inhibit-control -
unity7 signal-desktop:unity7 :unity7 -
wayland signal-desktop:wayland :wayland -
x11 signal-desktop:x11 :x11 -
Output of snap version
$ snap version
snap 2.55.3-1.el7
snapd 2.55.3-1.el7
series 16
centos 7
kernel 3.10.0-1160.80.1.el7.x86_64
Relevant log output
Nothing relevant in the log.
Teminal output of app
$ signal-desktop
[22870:1121/095010.877238:ERROR:platform_thread_posix.cc(153)] pthread_create: Operation not permitted (1)
Trace/breakpoint trap (core dumped)
Can you find info in your logs regarding this "operation not permitted"? SELinux denials, for example?
That's weird. Is this box using Wayland or X11? It's X11: $ echo $XDG_SESSION_TYPE x11
Can you find info in your logs regarding this "operation not permitted"? SELinux denials, for example? No selinux here: $ getenforce Disabled
There is noting in the logs regarding the operation not permitted.
I actually ran strace via "snap run --debug-log --strace signal-desktop" and found the call that results in "Operation not permitted", but I cannot figure out what it's trying to do: syscall_0x1b3(0x7ffda1358600, 0x58, 0x7fb56fe77850, 0x8, 0x7fb56d7a5640, 0x7ffda135871f) = -1 EPERM (Operation not permitted)
Looks to me like clone3 call...
Just to get a better picture, can you revert to the previous version of signal-desktop using snap revert and see if that works? Also let me know which version it reverts to, as you might have to go back two revisions.
We recently switched to core22 so that might be the cause of the issue.
It does not appear I can revert: $ snap revert signal-desktop error: cannot revert "signal-desktop": no revision to revert to $ snap list signal-desktop --all Name Version Rev Tracking Publisher Notes signal-desktop 5.63.1 405 latest/stable snapcrafters -
$ snap revert signal-desktop --revision=404 error: cannot revert "signal-desktop": cannot find revision 404 for snap "signal-desktop"
One can only revert to the revision they already have on disk. If this is a new installation that is not available, except for the developers of the signal snap who are signed to the snap store.
So, does anyone have an older image for me to test? From before core22 switch? I know I can use a local image file to install.
I promoted version 400 to beta. Can you refresh to the beta channel and try again? Thanks!
Thank you! I have refreshed to beta, which installed version 400. It works without issues. Thanks! I will be willing to help with testing further if you guys plan to figure out what causes this and fixing it.
According to the manpage:
The clone3() system call first appeared in Linux 5.3
It looks like your Linux 3.10.0 (kernel) is simply too old :'(
It looks like your Linux 3.10.0 (kernel) is simply too old :'(
So I guess there's some version of ubuntu that installs kernel 3.10.0-1160.80.1.el7.x86_64 by default? Is it possible to restrict the snap package to be installed only in newer versions of ubuntu?
I've investigated this, and it turns out that libseccomp (v2.3.1) is too old on CentOS 7 to handle newer system calls. This unfortunately results in the seccomp profiles not containg newer system calls (i.e clone3), and this then results in those system calls returning EPERM instead of ENOSYS (which glibc is built to handle).
If you manually build libseccomp from source and install it before installing signal-desktop (or you can remove it and install it to refresh the seccomp profile), then signal-desktop starts up again.
@Meulengracht Thanks for your help, that's awesome!
One question to understand this issue better: Will the current versions of libseccomp be able to handle future system calls? What I'm specifically curious about is whether we will have this issue again with CentOS 8 in a few years?
Note to anyone affected by this.
Due to an implementation detail of how channels and tracks work, a large number of users that came from a newer release, were accidentally switched to the beta channel. Since this can cause data loss, I had to close the beta channel so these people are back on the latest version.
If you're still using this snap op CentOS 7, I recommend to either switch to a newer version of libseccomp, or to switch to a non-snap version of this app.
@Meulengracht Thanks for your help, that's awesome!
One question to understand this issue better: Will the current versions of libseccomp be able to handle future system calls? What I'm specifically curious about is whether we will have this issue again with CentOS 8 in a few years?
No problems! Glad to be of help - I've put in a request at RedHat to update libseccomp (I cant promise it will be updated), however it's of course not a sustainable solution as there is no guarantee this wont happen again in the future.
We will look into seeing if we can come up with a more automatic solution instead.
Closing this issue as it's an upstream issue that we don't have control over.