[5.0 Beta] - error on linux related to libnss3.so

Tip: For anyone using Linux, if you get the error "Failed to load backend for 'application/pdf': libnss3.so: failed to map segment from shared object" when trying to open a PDF attachment, then it is easy to fix: Just re-download zotero.

This has happened to me three times already, and re-downloading zotero has fixed it for me every time. (Just re-download the standalone application folder, you don't need to touch the settings or storage.)

I guess something about libnss3.so gets messed up by the auto-updater sometimes.
  • There haven't been any other reports of this, but if you're seeing this repeatedly, if you could keep an eye on what version you're on and what you're updating to, we can try to replicate it with a specific version upgrade.
  • This happens to me pretty much continuously with v4.0.29.10 on Lubuntu 17.04. I'll try reinstalling now.
  • Reinstalling did not change things. I am also getting the message:

    Failed to load backend for 'application/pdf': libnss3.so: failed to map segment from shared object
  • I have had the same issue. I have a windows standalone install that I'm trying to have synced to a new linux standalone install.
  • could we get your distro, too?
  • ubuntu 17.04, however copying the extracted tar folder to a different directory than ~/Downloads seemingly fixed the issue.
  • edited July 7, 2017
    While opening a PDF in zotero standalone i received this error
    "Failed to load backend for 'application/pdf': libnss3.so: failed to map segment from shared object"

    Operating System is Ubuntu Gnome 17.04
    Looks like it's caused by evince, so simply install another PDF viewer to avoid this error.
    I installed foxit reader, and its working flawlessly. you can try others like xpdf or okular.
    To install okular on ubuntu run following command.
    sudo apt-get install okular
  • Oh, sorry I didn't say in my original post, but in case it helps, my operating system is Ubuntu 17.04.

    The problem continues to recur for me, after some but not every update. The fix I proposed above (replacing my "Zotero_linux-x86_64" folder with a freshly-downloaded one) is still working for me.
  • I did some research. The internet suggests that this error typically happens when you are trying to execute code from a directory (often /tmp) mounted as "noexec".

    For example:

    https://github.com/docker/compose/issues/1339

    https://support.datastax.com/hc/en-us/articles/115000550123-Graph-loader-throws-failed-to-map-segment-from-shared-object-warning

    Well, I do notice that zotero seems to use /tmp during updating (via the "mktemp -d" command) if I'm reading the code right. But then I'm stuck. My /tmp is not mounted at all, it's just a normal directory in /, which is a normal ext4 filesystem with normal settings, and also the /tmp permissions look correct ("drwxrwxrwt"). (But I'm not an expert!) So maybe it's something else? I dunno, I'm stuck. Any ideas?
  • Another update: I can reproduce the error on my computer by downloading zotero 5.0 from https://www.zotero.org/download/client/dl?channel=release&platform=linux-x86_64&version=5.0 , then letting it update to version 5.0.4. It restarts after the update, and then has the libnss3.so error message when I try to open any PDF.

    ...But, when I quit and restart zotero again, it's fixed!! (And it continues to work on future restarts.) That's nice! The easiest workaround I've ever seen :-) . I hope it continues to work that way on future updates, where I merely have to quit and restart zotero one extra time per update. But I will post again if I see (and can reproduce) the nastier version where the error persists even after opening and closing zotero many times.
  • Yeah, I can reproduce that. So what I think happens is that, when Zotero is updated, the new version runs as a child process of the old one — it looks like after the update there are defunct 'zotero' processes left behind — and so when it runs evince as a child process of the new one it's still trying to use the parent libnss3.so that doesn't exist anymore. Show File -> open still works, even though it's the exact same command line (evince /path/to/pdf), because that's starting a non-child evince process. Once you restart Zotero after the update, the defunct processes are cleared and this works normally.

    Unfortunately I doubt this is something we're going to be able to fix with the current updater (and I'm not sure it's actually new in 5.0 or there are just more people on the standalone app on Linux now), so people on Linux may have to put up with the extra restart for a while. (Obviously there won't be daily updates once things settle down a bit.)
  • I was getting the libnss3.so error opening PDFs, after upgrading to Ubuntu 17.10 and Zotero 5.0.28 (from Zotero 4 in Firefox). Restarting did not clear the problem. In a search for the source of "defunct" Zotero processes, I found that I still had a Unity package called unity-scope-zotero installed. I did a purge/compete removal of this package, and it solved the problem. (I don't have any use for the Unity package, but it looks like it can be reinstalled without messing up the "fix.")
  • Purging unity-scope-zotero fixed the issue for me. Thanks!
  • Purging unity-scope-zotero fixed the issue for me too. Thanks a lot!
  • Purging unity-scope-zotero also worked to resolve this issue for me as well. Thanks!
  • I also have this problem consistently with Zotero 5.0.45. For me it doesn't seem to be linked to upgrades, and I don't have any unity-scope-zotero package (I'm on Debian, so we don't have unity at all).

    I believe that the root cause of this problem is that the zotero startup script on Linux sets LD_LIBRARY_PATH to point to the zotero install's own library directory. For me it gets set to:

    LD_LIBRARY_PATH=/home/njs/bin/Zotero_linux-x86_64

    Then, when zotero tries to run a subprocess – for example, starting a PDF viewer – the subprocess *inherits* this environment variable setting, so it *also* ends up trying to use zotero's own libraries. (I confirmed this by examining /proc/$PID/environ for one of the broken evince processes.)

    In particular, if you look in that directory, you'll see that zotero ships a copy of libnss3.so for its own use. Then my system-installed evince tries to load libnss3.so, and expects that it will get the system-installed libnss3.so... but instead it gets zotero's version, and these aren't necessarily compatible. (After all, that's why zotero ships its own copy in the first place! It doesn't trust that the system copy will match what it needs.) This might also explain why some people above report that the problem comes and goes with upgrades: if zotero and your system are both using the same version of libnss3.so, then things will end up working out by chance; whenever they get out of sync, the problem comes back.

    To verify that this is the problem, I made a script called "zotero-evince" with the following contents:

    #!/bin/sh
    unset LD_LIBRARY_PATH
    exec evince "$@"

    When I tell zotero to use this as my PDF viewer (Edit -> Preferences -> Open PDFs using -> Custom...), then viewing PDFs always works. When zotero uses regular evince, then it always fails. So it's definitely the LD_LIBRARY_PATH that's causing the problem.

    This script works as a workaround. But it would be good if zotero could fix this to make the workaround unnecessary.

    I think the simplest solution would be: whenever zotero goes to spawn a subprocess like a PDF viewer, it should first restore the original LD_LIBRARY_PATH setting. Doing this reliably is a little tricky, since it's possible that users will have set their own custom LD_LIBRARY_PATH. One solution would be for the startup script to set an envvar ZOTERO_ORIGINAL_LD_LIBRARY_PATH, and then whenever zotero goes to launch a process, it could check if this envvar is set, and if so use it to overwrite the regular LD_LIBRARY_PATH for the child process.

    Another option would be to change how you distribute binaries so that you can stop setting LD_LIBRARY_PATH entirely, for example by giving the libraries unique names ("libnss3-zotero.so"), or by building the zotero binary with a custom DT_RUNPATH configuration. This is rather more technical and may require tools like patchelf, though; probably it's easier to change LD_LIBRARY_PATH before spawning children.
  • Many thanks. I also found that purging unity-scope-zotero fixed this problem for Zotero 5.0.47 and Ubuntu 17.10.
  • Just want to let you know, that purging unity-scope-zotero fixed the issue with Zotero 5.0.46 and Ubuntu 18.04. Thanks
  • I'm seeing this problem now with 5.0.48-beta.4+4acd17881 on 18.04. I don't have unity-scope-zotero installed.
Sign In or Register to comment.