Signal prevents OS shutdown

[liesdiedatei]

• I have searched open and closed issues for duplicates

---

Bug description

When I shutdown the computer while Signal Desktop is still active, the shutdown is delayed long enough for the computer to suspend in the meantime. After wake-up from suspend the shutdown will happen within 10 to 20 seconds. (Which is mostly not what I want, when waking it up from suspend.

Steps to reproduce

1. Have Signal Desktop active
2. Shut Down Computer via OS (no hard shut down via hardware buttons)
3. Wait.

Actual result:

Computer does not shut down or takes too long, so that it suspends in the meantime.

Expected result:

Computer should shut down within some seconds.

Screenshots

Not applicable.

Platform info

Signal version:

1.16.0

Operating System:

Ubuntu 18.04 x86-64 with Cinnamon v3.8, Linux Kernel 4.15.0-34-generic

Linked device version:

???

Link to debug log

not applicaple

[scottnonnenberg-signal]

What happens if you close Signal without shutting down the whole computer? Have you timed that?

Also, I would say that the log is useful. It will help us understand what Signal Desktop is doing on your machine before it shuts down.

[t-nelson]

I've experienced this as well. It's related to --start-in-tray (works fine w/o). Shutdown or logout both block for 3min or whatever, then the session sends SIGKILL to signal-desktop and finally proceeds.

I believe what's going on is that Electron is treating SIGINT the same as a close from the window manager. With the flag, this erroneously triggers close to tray, where it should in fact stop the app.

[t-nelson]

@scottnonnenberg-signal is any more info needed to make this actionable? Thanks!

[rrthomas]

I've started having this problem just recently, but I've used --start-in-tray for years. Running Signal 1.35.1 on Ubuntu 20.04.

[EvanHahn-Signal]

@rrthomas Would we be able to get some debug logs to help diagnose the issue? If possible, I'd love to see you try to shut down the machine with Signal running, then, after some time passes and the system doesn't shut down, grab the debug log. You can get that by going to View > Debug Log in the Desktop app, and posting the link here.

[rrthomas]

@EvanHahn-Signal Thanks for looking into this! As soon as I click Log Out, I can no longer interact with the application: the window title bar disappears, and the application does not respond to the mouse. My conclusion that it's still running comes from looking at /var/log/syslog to see the processes that systemd forcibly kills after waiting for 90 seconds, and my conclusion that Signal is the problem (for it is not the only process still hanging around at this point) comes from the fact that if I quit it before logging out, then logging out completes normally (i.e. in a second or two). So in short, I'm not sure how I'd get the debug log…What I could try doing if it would help is simulating a shutdown, i.e. sending Signal the signal (haha) that it would normally receive from the session manager?

[EvanHahn-Signal]

That'd be great! You should also be able to grab your logs off the disk. On Linux, it should be at ~/.config/Signal/logs/log.log.

[rrthomas]

Well, of course I can't make it happen now. So if it does happen again and the logs look worthwhile, I'll post them…Sorry!

[eclairevoyant]

This is happening for me 100% of the time following the steps below:

1. I have signal set to autostart via the following wrapper script (which is called from my window manager's startup config). It starts in tray and stays there.

   #!/usr/bin/env sh
   signal-desktop --ozone-platform=wayland --use-tray-icon
   

2. Open window manager.
3. Leave signal in tray.
4. Press power button or run systemctl poweroff to initiate shutdown.
5. Window manager stops, but I see system waiting for some process to time out before shutting down.
6. After 90s timeout, system shuts down.

The key step is leaving signal in the tray when shutting down. If signal's main window is open, this timing out issue doesn't happen.

grab the debug log. You can get that by going to View > Debug Log in the Desktop app

I don't see how that'd be possible, because the graphical environment is long dead when the system is waiting for shutdown.

However, here's the last few lines of ~/.config/Signal/logs/main.log when signal is in tray and a shutdown is initiated:

{"level":30,"time":"2023-06-04T13:10:02.388Z","msg":"Processed count: 0"}
{"level":30,"time":"2023-06-04T13:10:02.388Z","msg":"Messages per second: 0"}
{"level":30,"time":"2023-06-04T13:10:07.047Z","msg":"before-quit event {\"readyForShutdown\":false,\"shouldQuit\":false}"}
{"level":30,"time":"2023-06-04T13:10:07.048Z","msg":"System tray service: markShouldQuit"}
{"level":50,"time":"2023-06-04T13:10:07.050Z","msg":"Unhandled Error: Error: write EIO\n    at afterWriteDispatched (node:internal/stream_base_commons:160:15)\n    at writeGeneric (node:internal/stream_base_commons:151:3)\n    at Socket._writeGeneric (node:net:930:11)\n    at Socket._write (node:net:942:8)\n    at writeOrBuffer (node:internal/streams/writable:392:12)\n    at _write (node:internal/streams/writable:333:10)\n    at Writable.write (node:internal/streams/writable:337:10)\n    at Object.write ([REDACTED]/node_modules/pino/lib/multistream.js:71:16)\n    at Pino.write ([REDACTED]/node_modules/pino/lib/proto.js:210:10)\n    at Pino.LOG [as info] ([REDACTED]/node_modules/pino/lib/tools.js:56:21)"}

I compared this to a shutdown when signal's main window is open, and the difference I see is that last Unhandled Error line isn't present.

[ELT4N1N]

I do have the exact same problem and am using the same procedure as eclairevoyant.
I have also tried using the "Minimize to system tray"/"Start minimized to tray" settings of Signal itself instead of the command flag, but I get the same results.

Since I get the same main.log log messages, the only new information I can provide is the systemd error log:

Apr 15 22:53:37 ArchBox systemd[1]: session-1.scope: Stopping timed out. Killing.
Apr 15 22:53:37 ArchBox systemd[1]: session-1.scope: Killing process 1222 (signal-desktop) with signal SIGKILL.
Apr 15 22:53:37 ArchBox systemd[1]: session-1.scope: Failed to kill control group /user.slice/user-1000.slice/session-1.scope, ignoring: Invalid argument
Apr 15 22:53:37 ArchBox systemd[1]: session-1.scope: Failed with result 'timeout'.

If there is anything I can help with tracking down the bug, please tell me.

[indutny-signal]

@ELT4N1N sadly Arch Linux is not something that we support officially at the moment. Could you reach out to the maintainers of your package to see if they have any clues into what might be going on? Thank you!

[eclairevoyant]

This issue is present on multiple distros. Which distros do you officially support?

[indutny-signal]

@eclairevoyant Ubuntu and Debian linux.