Linux desktop client crashes on startup

I find it astonishing that this has not yet been fixed. Clearly it is not an issue of reproducibility because apparently it was reproduced internally four months ago. Is it difficult to fix? Is it low priority because Linux users are expected to be able to deal with unpolished software? Or because Linux users are (presumably) a small proportion of 1Password's (paying!) customer base, and therefore not worth the time?

Please excuse the tone; I bear no ill will towards anyone at 1Password, especially not Dave and the rest of the community team who have the unfortunate job of updating people on this when there are no updates to give. But it's extraordinary that a bug like this has survived several production releases of a commercial piece of software after having been reported a year ago.

Y

yjcb2

Your message is the voice for what I am feeling. Thanks a lot for this!

chris__hayes

For what it's worth, I used to have this issue for probably a year or two. But, at some point in the last month or so, the crashing on startup went away.

App: 1Password for Linux 8.11.14 (81114024)

Browser: Firefox 144 (Snap)

OS: Ubuntu 25.10 (Wayland)

1Password Employee

@chris__hayes

Thank you for the data point, I've shared it with our development team internally.

-Dave

I've been experimenting with this and after a bit of reverse engineering I managed to hack together a fix. The fix is simple in principle but it's quite a technical process. I thought I'd share it for those who want to try it. I'll describe the process for x86 because that's all I've tried, but you could probably do something similar on ARM.

As Dave figured out here, it seems like 1Password is not actually crashing (but it might as well be). The error message refers to an improper exit when 1Password was last running. There's a bug which means that 1Password takes ages to start up properly after the error message is dismissed, and an error message followed by nothing happening looks like a crash. The reason this happens on boot is, I think, because 1Password doesn't properly exit when the system is shutting down (unless it is manually closed first). When 1Password is launched after the system has booted, it checks for evidence of an unclean exit when it was last running. It will find this evidence because it didn't exit correctly on the previous shutdown. When it finds the evidence, it shows the popup and triggers the startup delay bug.

The "fix" is to patch 1Password so that it never sees any crash reports from the unclean exit. The function to patch is op_crash_reporting::crash_report::CrashReport::check_for_crash_reports, and it is in the binary /path/to/1Password installation/resources/app.asar.unpacked/index.node. On my Manjaro system this is /opt/1Password/resources/app.asar.unpacked/index.node.

Before it actually looks for any crash reports, check_for_crash_reports checks if op_crash_reporting::killswitch::CRASH_REPORTING_KILL_SWITCH is enabled. If it is, then it just returns zero, as though there are no crash reports. This is compiled as a conditional jump: "if the kill switch is enabled, then jump to the bit that returns zero". We patch the jump instruction so that it always jumps to the bit that returns zero, regardless of whether the kill switch is set. The caller of the function is led to believe that there are no crash reports, so 1Password starts normally, without a popup or delay.

The code moves around between 1Password versions (I've tried 8.11.12 and 8.11.14), so to find the exact location of the instruction to patch we use objdump to find the function by name and disassemble it:

objdump -FC -Mintel --disassemble="op_crash_reporting::crash_report::CrashReport::check_for_crash_reports" /opt/1Password/resources/app.asar.unpacked/index.node

Here's my annotated version of the relevant part of the output of that command (on 8.11.14):

                        | 000000000468d280 <op_crash_reporting::crash_report::CrashReport::check_for_crash_reports> (File Offset: 0x468c280):
                        |  468d280:       55                      push   rbp
                        |  468d281:       41 57                   push   r15
                        |  468d283:       41 56                   push   r14
                        |  468d285:       41 55                   push   r13
                        |  468d287:       41 54                   push   r12
                        |  468d289:       53                      push   rbx
                        |  468d28a:       48 81 ec 08 01 00 00    sub    rsp,0x108
                        |  468d291:       48 89 f3                mov    rbx,rsi
                        |  468d294:       49 89 fe                mov    r14,rdi
                        |  468d297:       48 8b 05 c2 2c 07 03    mov    rax,QWORD PTR [rip+0x3072cc2]        # 76fff60 <op_crash_reporting::killswitch::CRASH_REPORTING_KILL_SWITCH> (File Offset: 0x76fef60)
                        |  468d29e:       48 83 f8 02             cmp    rax,0x2
                        |  468d2a2:       0f 85 3b 02 00 00       jne    468d4e3 <op_crash_reporting::crash_report::CrashReport::check_for_crash_reports+0x263> (File Offset: 0x468c4e3)
 (load kill switch) --> |  468d2a8:       0f b6 05 b9 2c 07 03    movzx  eax,BYTE PTR [rip+0x3072cb9]        # 76fff68 <op_crash_reporting::killswitch::CRASH_REPORTING_KILL_SWITCH+0x8> (File Offset: 0x76fef68)
(check kill switch) --> |  468d2af:       a8 01                   test   al,0x1
          THIS JUMP --> |  468d2b1:       0f 84 95 01 00 00       je     468d44c <op_crash_reporting::crash_report::CrashReport::check_for_crash_reports+0x1cc> (File Offset: 0x468c44c)
                        |  468d2b7:       48 8d 7c 24 20          lea    rdi,[rsp+0x20]
                        |  468d2bc:       4c 89 f6                mov    rsi,r14
                        |  468d2bf:       48 89 da                mov    rdx,rbx
                        |  468d2c2:       e8 19 05 00 00          call   468d7e0 <op_crash_reporting::crash_report::crash_files> (File Offset: 0x468c7e0)

(The disassembly for 8.11.12 looks much the same, except that the memory addresses are different. Until this function is modified significantly in an update, it should be possible to identify the instructions above in future versions of 1Password.)

The instruction to patch is the je marked "THIS JUMP". We can read its memory address from the column on the left (here, it's 0x468d2b1). We need the file offset so we can edit the instruction. The difference between the memory addresses and file offsets is the difference between the two hexadecimal numbers on the first line of the disassembly: in this case, it's 0x468d280 - 0x468c280 = 0x1000. So the offset of the target instruction in the file is 0x468d2b1 - 0x1000 = 0x468c2b1 for this version. (The file offset of the target instruction is not always the same. It's different (0x2d7d9e1) in 8.11.12, for example.)

Open index.node in a hex editor and go to the file offset just calculated (0x468c2b1 for me). You should see the bytes 0f 84 xx xx xx xx (0f 84 95 01 00 00 in this case). Change the first two bytes to 48 e9. This changes the je instruction to jmp, which is an unconditional jump.

To save the file you will likely need root access, so it might be easiest to save elsewhere and sudo mv it into the correct location. I recommend keeping the old file as a backup. For instance, my unpatched binary is at /opt/1Password/resources/app.asar.unpacked/index.node.unpatched. The patched binary goes where the original was, so 1Password will use it instead. If you mess up the patch and 1Password stops working, you can just go back to the original binary without needing to reinstall anything.

You'll have to reapply the patch every time 1Password is updated. I did when I went from 8.11.12 to 8.11.14.

This patch doesn't work anymore on 8.11.16 because check_for_crash_reports no longer checks the kill switch (all of a sudden...?).

You can achieve the same effect as the above by patching op_crash_reporting::crash_report::crash_files like this: Find the first call to <FilterMap as Iterator>::next (it's not long after the call to Iterator::collect). Immediately after, there are cmp and je instructions. The je is encoded as 75 10. Change these bytes to 90 90 to swap the jump for two NOPs. (This edit was at 0x4743F85 in the file for me on 8.11.16-35.)

This works because the cmp and je are checking if next() returned None, and the next() is on an iterator of crash report files. NOPing the je makes execution fall through to the None case, so the loop that processes the crash report files never runs, and so crash_files returns nothing.

I'm going to keep using these patches because they completely fix the issue for me, both on boot and when 1P is terminated and restarted while the system remains running, but I'll avoid posting too much about it here because 1Password's own community forum isn't really the right place ;)

I found a blog post which has a nice idea for fixing the boot issue by creating a systemd service to delete the crash reports on boot so that 1Password doesn't see them. This is probably more useful for most people: https://oltdaniel.eu/notes/fix-1password-crash-report-popup/

F

frustrated_penguin23

Over 2 years since the Bug was reported and its still not fixed. @1P_Dave frankly, your statement that this issue is important to you cannot be true.

How would you react if you bought a brand new car and the dealer mentions on your way out: Oh and by the way, this car wont start on first try, just wait a couple of seconds and then try again. We are on it and will update you soon.

Please fix this asap, this affects our daily operation. Thanks

O

ombduqui

Agreed, it occurs more than just on the first try after a reboot.

For what it's worth, though Bitwarden is probably worth a shot instead:

1p: 8.11.22

Linux mint 22.2 cinnamon

Cinnamon 6.4.8

1Password Employee

@ombduqui

I'm sorry that 1Password is crashing on your Linux device as well. If you're seeing crashes that occur more often than just the first launch after a reboot then you might be running into a different issue. So that the team and I can take a closer look, I'd like to ask you to create and share a 1Password diagnostics report:

Send a diagnostics report (Linux)

Attach the diagnostics to an email message addressed to support@1password.com

With your email please include:

A link to this thread: https://www.1password.community/discussions/1password/linux-desktop-client-crashes-on-startup/110161/replies/165890
Your forum username: ombduqui

You should receive an automated reply from our BitBot assistant with a Support ID number. Please post that number here. Thanks very much!

-Dave

D

dooferlad

This is down to 1Password thinking that SIGTERM is a crash for some reason. You can get around it by deleting `.config/1Password/crashes/*` before starting the application, which you can put in a script and run on startup. The proper fix is, of course, not to interpret an external signal as a crash so the crash reporter needs fixing.

My guess is that SIGTERM is sent to everything still running when user session is stopped. It is a completely normal application signal and not a crash.

It wouldn't be so bad if the crash reporter didn't take ages to run. It does though. Even not sending a report isn't instant, which seems wild!

DenalB

Great finding! Hopefully devs will have a fix for us soon.

S

sjwells

Please can we bring this back on topic 🥺: on Linux, 1Password leaves stale files in ~/.config/1Password/crashes/ during a normal shutdown or reboot. On the next start, 1Password misinterprets these as a previous crash, logs a false crash, and delays startup. Clearing that directory (rm -rf ~/.config/1Password/crashes/*) before launching resolves the problem immediately. The discussion should focus on why crash artifacts persist across clean shutdowns and why they’re treated as real crashes on startup.

It shouldn't be crashing at all. The crash logs are produced because 1Password is incapable of handling the SIGTERM that it receives when the system is shutting down. The whole point of SIGTERM (as opposed to, say, SIGKILL) is to tell a process to perform a clean shutdown, but 1Password does something weird while trying to handle it and crashes, so the shutdown is not clean. (Or it at least thinks it crashes, maybe because it doesn't understand that SIGTERM is just a shutdown signal.) It would make sense for the crash logs to persist after that, because normally you might want to know that a program exited improperly the last time it was running. The popup is not because of a misinterpretation – it is actually reporting a real crash.

I have said this before in this discussion, and I will say it again: the solution is for 1Password to handle SIGTERM as though the user had asked it to quit via the GUI. That way, when the user asks the system to shut down and 1Password receives SIGTERM, it will exit gracefully, rather than crashing. No crash means no crash logs, so there's no crash reporting popup when 1Password next starts up. For some reason, nobody at 1PW has bothered to do this. There's a secondary bug, which is the delay that 1Password has for some reason before reporting the crash it found logs for, but that's less important. The most direct fix for the problems discussed here is to just handle the signal properly.

I don't know of any other piece of software (and certainly nothing commercial) that actually manages to crash when it receives SIGTERM.

1Password Employee

Hello! I've replied here.

-Dave

I just wrote this reply and in doing so something occurred to me: It's insane that it has got to the point where users are explaining in detail what the bug is and how to fix it (and it's not just me – other users have pointed out what's wrong as well), and still nobody on the dev team is doing anything about it. We could not have made it any easier.

This bug in particular is what's making me think that I will not be renewing my 1Password subscription. I like 1Password on the whole, but this is very poor, and frankly it seems my money would be better spent elsewhere. There is no excuse for not fixing this bug now that it has been made so plain what is causing the problem. (Or maybe there is an excuse? If it's not as simple as we think, why not ask us for advice? We've already shown that we're capable of figuring this stuff out.)

@1P_Dave When did you last speak to the dev team about this, and what did they actually say? Are they working on it, or is it just in a backlog somewhere, busy being ignored? Are they aware of the diagnoses that various users have made here?