search

signalapp / Signal-Desktop

A private messenger for Windows, macOS, and Linux.
https://signal.org/download
GNU Affero General Public License v3.0
14.17k stars 2.58k forks source link

Desktop Suspend/Resume Decouples Mobile Synchronization #6103

Open apiziali opened 1 year ago

apiziali commented 1 year ago

The recently closed bug report "[Linux: Signal doesn't reconnect after sleep or lock screen] #6027" looks quite similar to the issue I am seeing.

Bug Description

When I suspend and subsequently resume my Ubuntu 18.04 PC, the message queue of Signal Desktop no longer remains synchronized with my Signal Android. Every time I resume the PC, I need to restart Signal to see the latest messages already delivered to the mobile phone.

One other environment consideration is that this is a multi-user PC, with each of the two users logged in and running Signal. However, I believe I have seen the synchronization failure with only one active user session.

Steps to Reproduce

  1. Boot the Ubuntu 18.04 workstation ("elijah").
  2. Log into elijah.
  3. Signal Desktop is started by the Ubuntu Startup Applications, using the command: /usr/bin/signal-desktop --use-tray-icon --start-in-tray %U
  4. Double-click the desktop icon "Sleep Until Tonight." This invokes the shell program ~/bin/sleep_until_tonight. That program suspends the workstation using the command: rtcwake --mode mem --utc --time [WAKEUP_TIME], where "[WAKEUP_TIME]" is a valid time to resume, such as "1662094200." "rtcwake --mode mem" puts the workstation in ACPI state 3.
  5. Wait for a few Signal chats to be delivered to the mobile app.
  6. Resume elijah.
  7. Those new chats are absent in Signal Desktop.
  8. Quit Signal Desktop.
  9. Restart Signal Desktop.
  10. The chats delivered to the mobile app are now displayed in Signal Desktop.

Actual Result:

Chats that were delivered to the mobile app are not delivered to the desktop application, as described in "Steps to Reproduce."

Expected Result:

When the workstation is resumed, Signal Desktop ought to reflect the chats that were delivered while the workstation was suspended.

Screenshots

Platform Info

Signal Version:

5.56.0 ... Production.

Operating System:

Ubuntu 18.04.6 LTS (uname -a : "Linux elijah 5.4.0-124-generic #140~18.04.1-Ubuntu SMP Fri Aug 5 11:43:34 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux")

Linked Device Version:

Samsung Galaxy A21, Android 11, One UI Core 3.1.

Link to Debug Log

https://debuglogs.org/desktop/5.56.0/33574877e6a4c8cdbd74fec3f7f09269a6c0281d6bb5a25e0a0db48626841da5.gz https://debuglogs.org/android/5.47.3/83a1078f72b089d5d0f5996e170a937b768ab035e7ab9456d2141516ce61d8a4

debuglog.txt

apiziali commented 1 year ago

Nice observation! I never see this because whenever I resume my workstation, I run the following program:

killall -1 signal-desktop && sleep 15 start-signal exit 0

Hence, all Signal processes terminate, after catching SIGHUP if desired. This is start-signal:

/usr/bin/signal-desktop --use-tray-icon --start-in-tray $USER >/dev/null 2>&1 & exit 0

jeltz commented 1 year ago

I am seeing the same issue with Signal 6.16 on Debian bookworm with Xfce. And I do not get any similar issues with other electron apps so while the bug could be in electron it is probably also related to how you use electron. I also experince the issue that @megele does that sending messages does not work either plus the thing that just a normal quit does not necessarily resolve the issue.

jeltz commented 1 year ago

I get the following error when trying to send a message after the Signal client has ended up in a bad state. And, no, I am not comfortable attaching the whole log. It contains too much information about me.

debuglog-redact.txt

INFO  2023-04-28T10:22:50.690Z CompositionInput: Submitting message 1682677370690 with 0 ranges
INFO  2023-04-28T10:22:50.710Z Send pre-checks took 19 milliseconds
INFO  2023-04-28T10:22:50.710Z Sending message to conversation [REDACTED]5de ([REDACTED]7ec) with timestamp 1682677370690
WARN  2023-04-28T10:22:50.710Z restoreContact([REDACTED]5de ([REDACTED]7ec)) storage? false: not removed
WARN  2023-04-28T10:22:50.712Z lookupOrCreate: Called with neither e164 nor uuid! reason: MessageModel.getSenderIdentifier
INFO  2023-04-28T10:22:50.713Z enqueueMessageForSend: saving message [REDACTED]392 and job [REDACTED]be7
INFO  2023-04-28T10:22:50.739Z JobQueueDatabaseStore adding job [REDACTED]be7 to queue "conversation"
INFO  2023-04-28T10:22:50.739Z conversation job queue: added new job [REDACTED]be7
INFO  2023-04-28T10:22:50.739Z ConversationModel([REDACTED]5de ([REDACTED]7ec).sendMessage(1682677370690): db save took 26ms
INFO  2023-04-28T10:22:50.740Z conversation job queue: enqueuing job [REDACTED]be7
INFO  2023-04-28T10:22:50.742Z enqueueMessageForSend([REDACTED]5de ([REDACTED]7ec)): clearDraft(true)
flantel commented 1 year ago

Also seeing this issue. Linux Mint 21.1 XFCE with latest Signal.

This is a desktop and it never suspends, only screenl ock.

timp34 commented 1 year ago

I am also seeing same loss of connection with another electron based app. Decred Wallet https://decred.org/wallets/ Screen lock or suspend resume results in Signal and Decred wallet losing their network connection. Both have to be restarted to get connectivity back. I am also running another system with KDE on debian as opposed to XFCE and have not had the issue at all on that system with either app.

apiziali commented 1 year ago

Scott, can you give us an update on the status of this issue? Also, the Signal Foundation recently announced it was dropping support for my particular platform, Ubuntu 18.04. However, I have an Ubuntu Pro subscription that will continue providing security updates through 2028. Will support for Ubuntu Pro 18.04 also be dropped?

scottnonnenberg-signal commented 1 year ago

Ubuntu 20.04 is the lowest version of Ubuntu we will support going forward. This is because Electron (Chromium, actually) has dropped support for older platforms.

The status of the issue is that it's a low-level Electron problem, and we don't have enough information to provide a crisp bug report to the Electron folks. Hopefully it will be fixed with future updates, since they're always fixing bugs, but it would be ideal if we could get a lot more crisp with this issue so we can give them simple, repeatable repro steps to verify their fix.

ghost commented 11 months ago

Happens also with Signal 6.26.0 and Ubuntu 22.04.2 LTS. How can this issue be made more 'crisp'?

When Signal is in the disconnected state, sending a message to self does not work, the message status shows an empty circle spinning indefinitely. Quitting Signal via the tray icon or via the File->Quit menu does not work immediately, it does quit after a minute or so.

Messages written while in the limbo state seem to be send after the restart of Signal, but then appear out of chronological order. I am not sure if the sending of limbo messages worked every time.

scottnonnenberg-signal commented 11 months ago

@sirius-c We need a very specific, reliable set of steps to get it to happen. What's specific about your setup that causes this to happen. When our (people at Signal) linux machines go to sleep, this doesn't happen.

The most ideal situation is that we'd be able to get into that state on our machines, and would be able to poke and prod at the issue, maybe fixing it ourselves, but certainly gathering enough information to report it to Electron.

ghost commented 11 months ago

Thanks, but this does in no way help me or others who suffer from this bug to help you. We cannot provide a reliable recipe to reproduce it on your side since we do not know your set-ups, just as you do not know ours exactly. It occurs on my side all the time and I have to my understanding a perfectly normal Linux installation.

Quite a lot of diagnostic information has already been provided to Signal by the various contributors to this thread, I believe now it is up to you to do what is necessary to track it down further - maybe add more logging to Signal so that our debug logs can help (which I gather is not the case now).

It was working properly some longer time in the past, so commit histories might provide insight. The date when this or similar issues was submitted could help in narrowing down the time span.

nigiord commented 11 months ago

@sirius-c Some stuff that could help to narrow it down:

From my experience on Debian SID + XFCE, I think it’s more a "screen locking" issue rather than a suspend issue. I’ll try to find some time to test this over the week-end, but if anyone following this issue could test my suggestions above, or provide any information regarding other desktop environments, don’t hesitate.

ghost commented 11 months ago

Thanks for coming back with concrete questions.

I do use XFCE and xflock4 is called when I manually lock the screen upon leaving the desk. I am not sure what is called when I close the laptop, but 'Suspend' is selected as action in the power manager when closing (both on battery and when on plugged in), and also 'Lock screen when going to sleep' in Security. I do need to enter my password after suspension.

The issue with Signal does not occur after a short screen locking or suspension of a few minutes. I will try to determine next week when back at this computer if there is a clear threshold time.

I do have three systems with the same OS, two laptops and one desktop, and the problem occurs only with one of the laptops. This laptop has a long history of following LTS upgrades.

I am happy to try other screen lockers once I determined the threshold time.

scottnonnenberg-signal commented 11 months ago

@sirius-c When talking about specifics, the fact that you have a couple computers and it only happens on one - that's a major clue. What is the exact difference between those two computers (hardware, laptop vs. desktop, settings, software installed, drivers) or your behavior with them (longer suspends, no suspend at all, etc.)?

apiziali commented 11 months ago

I would love to assist guys, but Signal is dropping support for my Ubuntu 18.04 system in a few weeks. Hence, I migrated my use of Signal Desktop to a Windows 10 virtual machine. I do not suspend and resume that VM.

ghost commented 11 months ago

I can confirm now that the issue appears with screen locked but computer not suspended. I do not know the threshold time, but after 90 minutes Signal did not sent messages anymore. Picking up a suggestion form @nigiord above, I will investigate different screen lockers.

@scottnonnenberg-signal: I doubt that at this stage of problem investigation the exact differences between my computers matter - they have different keyboards connected, different processors, different colours, ... It would be good to know from the Signal experts which settings likely matter.

The actual command run by xflock4 for me is light-locker-command --lock.

ghost commented 11 months ago

Quitting signal when in the problematic state takes about one minute until the the Signal icon vanishes from the tray.

ghost commented 11 months ago

A 10-15 minute suspend did not result in a problem with Signal.

ghost commented 10 months ago

After switching to xscreensaver instead of light-locker, Signal does not loose synchronization and message sending works also after hour-long screen locks. I do not see any issues with any other programs or know of related bugs reported to light-locker, so I do not know who is likely the culprit.

obadz commented 9 months ago

I have the same issue with messages which don't arrive after long suspends using light-locker. As mentioned here, signal-desktop does not actually shut down when the window is closed in this state, it needs a kill or some time.

megele commented 9 months ago

I switched from light-locker to xscreensaver too and this seems indeed to help. Any pointers on how to provide better input/feedback would be appreciated.

obadz commented 9 months ago

This Signal (or Electron?) bug is likely triggered by this: https://github.com/the-cavalry/light-locker/issues/107#issuecomment-375083958 and is also probably related to https://github.com/the-cavalry/light-locker/issues/164

The issue here is, after being suspended for too long, signal-desktop is unable to recover and start receiving messages again.

ehosca commented 6 months ago

this still happens with : 6.42.1 after waking up from hibernation, Signal thinks it's disconnected from the internet, displays the yellow Wifi + Exclamation Point icon and never reconnects.

obadz commented 5 months ago

Having to kill signal from the command line 10x per day is quite frustrating..

fhackenberger commented 4 months ago

I can confirm this still being an issue on Ubuntu 23.04 with:

App version: 6.46.0
Environment: production
Linux version: "Ubuntu 23.04"
Node version: 18.17.1
OS version: #40-Ubuntu SMP PREEMPT_DYNAMIC Tue Nov 14 14:18:00 UTC 2023
Time: 1708611358467
User agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Signal/6.46.0 Chrome/118.0.5993.159 Electron/27.2.3 Safari/537.36

I've attached the relevant parts of the log. The log starts while signal is still running normally. Then after hibernating the computer and waking it up the next day, Signal stops receiving or sending messages.

debuglog-signal.txt

obadz commented 3 months ago

To be double checked, but maybe this was fixed in v7.1.1 -> v7.2.1 ?

jamiebuilds-signal commented 3 months ago

Awesome, I'll close this then and if people experience it again they can let us know

obadz commented 3 months ago

Nope, bug's still there..

obadz commented 2 months ago

@jamiebuilds-signal, can you please reopen? This bug isn't fixed.

trevor-signal commented 2 months ago

@obadz would you be willing to try the beta version to see if that helps?

obadz commented 2 months ago

Hi @trevor-signal, I tried 7.4.0-beta.2 and it's not any better.

fnevgeny commented 1 month ago

I am not adding anything new; just to note this annoying bug has been with me for years. Each day, after the over-the-night suspension, I routinely begin my session by killing Signal and restarting it. Currently Ubuntu 22.04. While on another (office, never hybernating) computer with the same OS, it never happens.

trevor-signal commented 1 month ago

@fnevgeny are you using light-locker as noted above?

fnevgeny commented 1 month ago

No, just manually selecting "Power off->Suspend" (which I suppose does something like systemctl suspend -i).

trevor-signal commented 1 month ago

@fnevgeny can you share debug logs after this happens? And when you resume, does the app show that it's in a disconnected state? Do any messages arrive? Can any messages be sent? Thanks!

fnevgeny commented 1 month ago

No, there is no indication that it's in a disconnected state. I can neither send (there is a single circle, rotating forever, see below) nor receive new messages. gkrellShoot_05-15-24_220410

Attaching the logs. In fact, this time, Signal survived over three nights. But the last suspend was fatal; the logs starting at 2024-05-15T06:45:02.048Z are from the limbo state. debuglog2.txt.gz

fnevgeny commented 1 month ago

BTW, in this "limbo" state, File->Quit doesn't really quit the application, it only closes the GUI. So running the app again says

making app single instance
quitting; we are the second instance

and the GUI reappears (but again, it can neither send nor receive messages).

So I have to really kill the process.

trevor-signal commented 1 month ago

BTW, in this "limbo" state, File->Quit doesn't really quit the application, it only closes the GUI. So running the app again says

making app single instance
quitting; we are the second instance

and the GUI reappears (but again, it can neither send nor receive messages).

So I have to really kill the process.

Thanks, @fnevgeny , this info is useful. From the logs it looks like one of our worker threads is not responding after resume. We'll continue to investigate.

tonyarkles commented 1 week ago

I am experiencing this as well with Debian 12.5 and Signal Desktop. The machine is never suspended but I am using Xfce and lock my screen when I'm away from the computer. I'm going to be away from home for a few days but am happy to help debug this issue when I get back.