signal-desktop won't start after upgrade to 7.24.X (and sudo user pw change)

[gleanfield]

Using a supported version?

• I have searched searched open and closed issues for duplicates.
• I am using Signal-Desktop as provided by the Signal team, not a 3rd-party package.

Overall summary

Problem: Signal Desktop does not start after upgrade to 7.24.0 or 7.24.1

My OS: Ubuntu 22.04.5 LTS
signal-desktop version at issue: 7.24.0 or 7.24.1
last known working version of signal-desktop: 7.22.2

Steps to reproduce

1. Run Ubuntu 22.04.5 LTS

2. Install signal-desktop version 7.22.2 and confirm working

3. Change primary sudo user password (I'm kicking myself for finally doing this, but not sure it's even related to this issue)

4. Install signal-desktop version 7.24.X (not certain on 7.24.0 or 7.24.1)

5. Restart machine

6. Open signal-desktop normally (not from terminal)

7. Receive the following popup: Unlock Login Keyring. Authentication required. The password you use to log in to your computer no longer matches that of your login keyring.

8. Unfortunately it's not clear if I entered the password correctly. (It wasn't clear that this popup was even related to the Signal startup process.)

9. Next, receive: Database Error. A database error occurred. You can copy the error and contact Signal support to help fix the issue. If you need to use Signal right away, you can delete your data and restart. Contact support by visiting: https://support.signal.org/error. Options: 1) Copy error and quit 2) Delete data and restart

10. Click option 1 (but note nothing gets copied to clipboard)

11. run signal-desktop from terminal and receive:

    Set Windows Application User Model ID (AUMID) { AUMID: 'org.whispersystems.signal-desktop' }
    NODE_ENV production
    NODE_CONFIG_DIR /opt/Signal/resources/app.asar/config
    NODE_CONFIG {}
    ALLOW_CONFIG_MUTATIONS undefined
    HOSTNAME nkps
    NODE_APP_INSTANCE undefined
    SUPPRESS_NO_CONFIG_WARNING undefined
    SIGNAL_ENABLE_HTTP undefined
    userData: /home/mm/.config/Signal
    config/get: Successfully read user config file
    config/get: Successfully read ephemeral config file
    making app single instance
    {"level":30,"time":"2024-09-18T20:34:54.481Z","msg":"got fast localeOverride setting null"}
    {"level":30,"time":"2024-09-18T20:34:54.481Z","msg":"app.ready: hour cycle preference: UnknownPreference"}
    {"level":30,"time":"2024-09-18T20:34:54.481Z","msg":"app.ready: preferred system locales: en-US, en"}
    {"level":30,"time":"2024-09-18T20:34:54.482Z","msg":"locale: Supported locales: af-ZA, ar, az-AZ, bg-BG, bn-BD, bs-BA, ca, cs, da, de, el, en, es, et-EE, eu, fa-IR, fi, fr, ga-IE, gl-ES, gu-IN, he, hi-IN, hr-HR, hu, id, it, ja, ka-GE, kk-KZ, km-KH, kn-IN, ko, ky-KG, lt-LT, lv-LV, mk-MK, ml-IN, mr-IN, ms, my, nb, nl, pa-IN, pl, pt-BR, pt-PT, ro-RO, ru, sk-SK, sl-SI, sq-AL, sr, sv, sw, ta-IN, te-IN, th, tl-PH, tr, ug, uk-UA, ur, vi, yue, zh-CN, zh-HK, zh-Hant"}
    {"level":30,"time":"2024-09-18T20:34:54.482Z","msg":"locale: Preferred locales: en-US, en"}
    {"level":30,"time":"2024-09-18T20:34:54.482Z","msg":"locale: Locale Override: null"}
    {"level":30,"time":"2024-09-18T20:34:54.483Z","msg":"locale: Matched locale: en"}
    {"level":40,"time":"2024-09-18T20:34:54.509Z","msg":"intl.onWarn [@formatjs/intl] "defaultRichTextElements" was specified but "message" was not pre-compiled. \nPlease consider using "@formatjs/cli" to pre-compile your messages for performance.\nFor more details see https://formatjs.io/docs/getting-started/message-distribution"}
    {"level":30,"time":"2024-09-18T20:34:54.509Z","msg":"locale: Text info direction for en: ltr"}
    {"level":30,"time":"2024-09-18T20:34:54.510Z","msg":"getSQLKey: decrypting key"}
    {"level":30,"time":"2024-09-18T20:34:54.510Z","msg":"getSystemTraySetting got value DoNotUseSystemTray"}
    {"level":30,"time":"2024-09-18T20:34:54.511Z","msg":"getSystemTraySetting returning DoNotUseSystemTray"}
    {"level":30,"time":"2024-09-18T20:34:54.512Z","msg":"app ready"}
    {"level":30,"time":"2024-09-18T20:34:54.512Z","msg":"starting version 7.24.1"}
    {"level":30,"time":"2024-09-18T20:34:54.512Z","msg":"media access status [object Undefined] [object Undefined]"}
    {"level":30,"time":"2024-09-18T20:34:54.514Z","msg":"got fast theme-setting value dark"}
    {"level":30,"time":"2024-09-18T20:34:54.526Z","msg":"got fast theme-setting value dark"}
    {"level":30,"time":"2024-09-18T20:34:54.526Z","msg":"got fast spellcheck setting true"}
    {"level":30,"time":"2024-09-18T20:34:54.527Z","msg":"Initializing BrowserWindow config: {"show":false,"width":1908,"height":2014,"minWidth":300,"minHeight":200,"autoHideMenuBar":false,"titleBarStyle":"default","backgroundColor":"#121212","webPreferences":{"devTools":false,"spellcheck":true,"enableBlinkFeatures":"CSSPseudoDir,CSSLogical","enablePreferredSizeMode":true,"nodeIntegration":false,"nodeIntegrationInWorker":false,"sandbox":false,"contextIsolation":true,"preload":"[REDACTED]/preload.bundle.js","backgroundThrottling":true,"disableBlinkFeatures":"Accelerated2dCanvas,AcceleratedSmallCanvases"},"icon":"[REDACTED]/images/signal-logo-desktop-linux.png","x":6,"y":43}"}
    {"level":30,"time":"2024-09-18T20:34:54.575Z","msg":"spellcheck: user locales: ["en-US","en"]"}
    {"level":30,"time":"2024-09-18T20:34:54.575Z","msg":"spellcheck: available spellchecker languages: ["af","bg","ca","cs","cy","da","de","de-DE","el","en","en-AU","en-CA","en-GB","en-GB-oxendict","en-US","es","es-419","es-AR","es-ES","es-MX","es-US","et","fa","fo","fr","fr-FR","he","hi","hr","hu","hy","id","it","it-IT","ko","lt","lv","nb","nl","pl","pt","pt-BR","pt-PT","ro","ru","sh","sk","sl","sq","sr","sv","ta","tg","tr","uk","vi"]"}
    {"level":30,"time":"2024-09-18T20:34:54.575Z","msg":"spellcheck: setting languages to: ["en-US","en"]"}
    2024-09-18 15:34:54.850: ERROR CORE sqlcipher_page_cipher: hmac check failed for pgno=1
    2024-09-18 15:34:54.850: ERROR CORE sqlite3Codec: error decrypting page 1 data: 1
    2024-09-18 15:34:54.850: ERROR CORE sqlcipher_codec_ctx_set_error 1
    {"level":40,"time":"2024-09-18T20:34:54.851Z","msg":"MainSQL: Database log code=26: file is not a database in "PRAGMA journal_mode = WAL""}
    {"level":30,"time":"2024-09-18T20:34:54.851Z","msg":"MainSQL: migrateDatabase: Migration without cipher change failed"}
    2024-09-18 15:34:54.909: ERROR CORE sqlcipher_page_cipher: hmac check failed for pgno=1
    2024-09-18 15:34:54.909: ERROR CORE sqlite3Codec: error decrypting page 1 data: 1
    2024-09-18 15:34:54.909: ERROR CORE sqlcipher_codec_ctx_set_error 1
    {"level":40,"time":"2024-09-18T20:34:54.909Z","msg":"MainSQL: Database log code=26: statement aborts at 2: [PRAGMA user_version] file is not a database"}
    {"level":50,"time":"2024-09-18T20:34:54.909Z","msg":"MainSQL: Database startup error: SqliteError: file is not a database\n at Database.pragma ([REDACTED]/node_modules/@signalapp/better-sqlite3/lib/methods/pragma.js:11:31)\n at getUserVersion ([REDACTED]/ts/sql/util.js:132:13)\n at migrateSchemaVersion ([REDACTED]/ts/sql/Server.js:404:54)\n at openAndMigrateDatabase ([REDACTED]/ts/sql/Server.js:436:5)\n at openAndSetUpSQLCipher ([REDACTED]/ts/sql/Server.js:458:14)\n at initialize ([REDACTED]/ts/sql/Server.js:496:10)\n at MessagePort. ([REDACTED]/ts/sql/mainWorker.js:69:41)\n at [nodejs.internal.kHybridDispatch] (node:internal/event_target:820:20)\n at MessagePort. (node:internal/per_context/messageport:23:28)"}
    {"level":50,"time":"2024-09-18T20:34:54.910Z","msg":"Failed to get zoom factor {"name":"SqliteError"}"}
    {"level":30,"time":"2024-09-18T20:34:55.241Z","msg":"got fast theme-setting value dark"}
    {"level":50,"time":"2024-09-18T20:34:56.032Z","msg":"sql.initialize was unsuccessful; returning early"}
    {"level":30,"time":"2024-09-18T20:34:56.032Z","msg":"close event {"readyForShutdown":false,"shouldQuit":false}"}
    {"level":30,"time":"2024-09-18T20:34:56.032Z","msg":"maybeRequestCloseConfirmation: Checking to see if close confirmation is needed"}

12. Per Signal cannot start anymore! #6996, try downgrading to v 7.21.0, 7.22.2, and 7.15.0 (via sudo apt install signal-desktop=X.XX.X) with no success. I believe I restarted machine for each new version.

13. I also did some experimenting with changing the sudo password back to original and confirming Login Keyring was unlocked before trying to open signal-desktop, but that didn't help.

Following the first error, I made a backup of ~/.config/Signal. I definitely did not click "Delete data and restart".

I'm hoping to avoid losing desktop access to years of correspondence.

Any suggestions would be greatly appreciated. Thank you.

Expected result

signal-desktop opens normally

Actual result

First error received:

I believe I received when testing v 7.21.0 or 7.22.2:

I believe I received when testing v 7.21.0 or 7.22.2:

I believe I received when testing v 7.21.0 or 7.22.2:

Fairly certain this error was received when testing 7.15.0:

Screenshots

No response

Signal version

Described in detail above

Operating system

Ubuntu 22.04.5 LTS (EDIT: more specifically, Xubuntu so essentially Ubuntu + XFCE desktop)

Version of Signal on your phone

Android 7.16.4

Link to debug log

No response

[jamiebuilds-signal]

I think this is a permissions issue on the database file. Looks like it failed before we got to the step where we fix the file permissions up

sql.initialize was unsuccessful; returning early

Can you go to your user data directory and check what the permissions of these files are:

'config.json',
'sql/db.sqlite',
'sql/db.sqlite-wal',
'sql/db.sqlite-shm',

From your logs:

userData: /home/mm/.config/Signal

[gleanfield]

-rw-------   1 mm mm   310 Sep 18 16:05  config.json

-rw-------  1 mm mm 250732544 Sep 18 13:31 db.sqlite

I don't have sql/db.sqlite-wal or sql/db.sqlite-shm.

[jamiebuilds-signal]

Unfortunately it's not clear if I entered the password correctly. (It wasn't clear that this popup was even related to the Signal startup process.)

I assume you did enter it correctly, I doubt that the keyring prompt accepted an invalid password. This is part of the app startup as the keyring contains the password used by signal desktop to decrypt your database.

[gleanfield]

I assume answer is yes, but just to confirm: without making this current issue worse, can I install and link to my phone signal-desktop-beta v 7.25.0-beta.2 from repo and/or the Snap? https://snapcraft.io/install/signal-desktop

[jamiebuilds-signal]

If you install a separate copy of the app (ensuring that you aren't uninstalling or replacing the existing app which will delete your local database), you can run a separately linked version of the app under a different name (such as the beta), but you won't get all of your old messages from the other copy of the database.

[ayumi-signal]

Hi @gleanfield, so sorry this is happening for you. Appreciate the detailed steps you took. I tried to follow the exact steps but was unable to reproduce it. The steps I took were: using Ubuntu 22, installing and running 6.22.2, changing password, installing 6.24.1, and encountering the dialog "keyring password changed". However it worked for me.

Unfortunately the keyring or password in it might be corrupted at this point :( As a final check, are you using a different keyring backend (instead of libsecret); and you could check the system app Passwords and Keys to see if there's entries there? If you had VS Code or other chrome-based browsers installed, then you could check if those apps are also experiencing keyring issues.

[gleanfield]

@ayumi-signal, thank you for your efforts. I'm assuming you mean versions 7.22.2 and 7.24.1, respectively.

I'm not doing anything other than the default backend. I see I have libsecret-1-0 installed.

What did you mean by this?
"Unfortunately the keyring or password in it might be corrupted at this point"

I run seahorse (GUI for viewing keyring) and overall things seem normal i.e. nothing appears corrupted. I also use Cryptomator and had to put in new sudo password there and no issues.

Is it possible that my sudo password change is just a red herring i.e. just a coincidence and not actually the cause of this issue?

Is it possible that a future version of Signal may bring my database back to life?

[ayumi-signal]

I'm assuming you mean versions 7.22.2 and 7.24.1, respectively.

Oops yes, and checking my history that's what I tested.

"Unfortunately the keyring or password in it might be corrupted at this point"

By this I meant it looks like the signal db encryption key doesn't work anymore, based on the app being unable to use the key to decrypt the local database.

We're aware of other local database issues and are working on a way to improve it. Until then, you could try to link a new desktop (either backup then move ~/.config/Signal or use the beta which has its own data directory) and always run the app with --password-store="basic" which would bypass the local DB key encryption, as long as you use the flag every time. (flag reference: https://www.electronjs.org/docs/latest/api/safe-storage#safestoragegetselectedstoragebackend-linux)

[gleanfield]

signal-desktop version 7.25.0 also not working.

[mosbat]

Just a question. Is this issue assuming that the person was already logged in to Signal Desktop before changing password?

Disclaimer:
I'm getting myself familiarized with the project; so appreciate your patience if am asking newbie questions here.

[gleanfield]

@mosbat, good question. I tried to retrace my steps but can't say definitely either way. However, I would say it's more likely than not that I had signal-desktop running at the time of the sudo password change. I'm also confident the problem occurred following installation of a new version, restarting my machine, and then attempting to open the new version of signal-desktop for the first time.

[mosbat]

@mosbat, good question. I tried to retrace my steps but can't say definitely either way. However, I would say it's more likely than not that I had signal-desktop running at the time of the sudo password change. I'm also confident the problem occurred following installation of a new version, restarting my machine, and then attempting to open the new version of signal-desktop for the first time.

Yes, this is what I thought as well. Could be the old Signal data during the process contributing factor into this issue as well.

[indutny-signal]

Unfortunately, we can't really recommend much aside from @ayumi-signal 's suggestion to relink and run with the password store CLI option. Sorry!

[gsedej]

Hello. I would also like to add, that same thing happened to me.

I changed my Ubuntu 22.04 password using "sudo su" and then passwd myusername since i have too simple password to be accepted by gnome password manager. Even "passwd" is not accepting except when in "sudo su". After changing password, the linux shell was using "simple" password, but when "pop-over" (after auto-login) needed "hard" password.

I also did the regular (~weekly) updates (apt dist-upgrade).

Around that time, signal stopped working with "code=26". Other apps that require password works (e.g. NextCloud client).

I did install separate -beta version, just to be able to use desktop client but without history.

What I did notice that was not mentioned before is that ".config/Signal/sql" folder has only one file db.sqlite, but ".config/Signal Beta/sql" also hase files "db.sqlite-shm" and "db.sqlite-wal"

edit: how should one be able to see "seahorse" or "libsecret" Signal entries. Is it as "Chromium Safe Storage"?

[Altonss]

Same issue happened to me, see flathub/org.signal.Signal#729 (comment) for details.

[Altonss]

edit: how should one be able to see "seahorse" or "libsecret" Signal entries. Is it as "Chromium Safe Storage"?

@gsedej On my computer it indeed had no "title", I had to search through the chrome safe storage entries, to find the one corresponding to signal :)

[flaphoschi]

I'm rather sure that this bug has nothing to do with Ubuntu or the password change. I've got the same twice today and lost all my messages. Using Archlinux, didn't changed any password or touched the keyring (Seahorse).

Basically I the choice between dead and dead by being banned?

The left button doesn't copy anything. The right button kills the data.
I think this should be handled as kind blocker.

Interestingly this doesn't happen on a nearly identical installation, both running 7.24.1. The only action I did was closing and opening Signal once rather quickly on the affected system?

[flaphoschi]

Same issue happened to me, see flathub/org.signal.Signal#729 (comment) for details.

Now I remember that flatpak mentioned something about "org.freedesktop.Secrets to org.freedesktop.secrets".

Can this be the reason?

[flaphoschi]

Confirmed

The unaffected systems wants to do this with flatpak update

Looking for updates…

New org.signal.Signal permissions:
    dbus access [1]

    [1] org.freedesktop.secrets


        ID                              Branch          Op          Remote          Download
 1.     com.getpostman.Postman          stable          u           flathub         < 150.3 MB
 2.     org.signal.Signal               stable          u           flathub         < 170.2 MB

I will not install it. I'm rather sure this will brick Signal.
@Developers: While this is just a belly feeling, I suggest reverting that change immediately. If I'm right you're bricking all Flatpaks right now 😞

[Altonss]

Indeed a lot of people are reporting the same issue here too: flathub/org.signal.Signal#723

[BentHaase]

Indeed a lot of people are reporting the same issue here too: flathub/org.signal.Signal#723

tl;dr for anyone experiencing this -> if you don't have a recent backup of your Signal folder your data is permanently lost.

[posita]

Indeed a lot of people are reporting the same issue here too: flathub/org.signal.Signal#723

tl;dr for anyone experiencing this -> if you don't have a recent backup of your Signal folder your data is permanently lost.

I would like to propose that, due to what appears to be fairly widespread message history loss on desktop, feature requests like these deserve revisiting and possible elevation of priority.