1434666 - updater failing on Linux (cannot find libraries)

Status: RESOLVED DUPLICATE of bug 1434033

(Toolkit :: Application Update, defect, P2)

Description

[Arthur Edelstein [:arthur]]

In Tor Browser, the patch from bug 1159090 (https://hg.mozilla.org/mozilla-central/rev/6e0c202e4469) had to be reverted because the updater was failing. Here's the original description from https://trac.torproject.org/18900:

"""
When testing the 6.0a5 updater using our own Linux64 build, the updater fails to run because it cannot locate Mozilla shared libraries:

    error while loading shared libraries: libmozsqlite3.so: cannot open shared object file: No such file or directory

Code in toolkit/xre/nsUpdateDriver.cpp is supposed to add the Browser directory to LD_LIBRARY_PATH. We will need to see why that is not happening.
"""

We'd like to propose investigating and fixing this issue (without necessarily reverting the 1159090 patch).

Comment 1

[Robert Strong (they/them - no direct email)]

There are ci tests that launch firefox and then launch the updater and we also haven't had client bug reports for this issue. Any idea why this is happening with tor?

Comment 2

[Arthur Edelstein [:arthur]]

Here's my understanding from inspecting the code. On Linux, Tor Browser has a startup script that sets LD_LIBRARY_PATH to
  ${TOR_BROWSER_MAIN_DIR}/Browser/TorBrowser/Tor/
where the Tor binary is located. So, when the AppendToLibPath is asked to append
  ${TOR_BROWSER_MAIN_DIR}/Browser/
to LD_LIBRARY_PATH, it decides that the directory is already present and doesn't add it. (This seems to be related to Mark's concern in bug 1159090 comment 4.)

Comment 3

[Robert Strong (they/them - no direct email)]

That makes sense and thank you!

Comment 4

[Arthur Edelstein [:arthur]]

Attachment: 0001-Bug-1434666-Avoid-path-aliasing-in-AppendToLibPath.patch

Comment 5

[Arthur Edelstein [:arthur]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=853310922146223920a1cd7ed3817ad3258c18e4

Comment 6

[Robert Strong (they/them - no direct email)]

Comment on attachment 8950475 [details] [diff] [review]
0001-Bug-1434666-Avoid-path-aliasing-in-AppendToLibPath.patch

Nicely done and thanks!

Comment 7

[Arthur Edelstein [:arthur]]

Thanks for the review!

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/855eb2e4c43d
Avoid path aliasing in AppendToLibPath r=rstrong

Comment 9

[Narcis Beleuzu [:NarcisB]]

https://hg.mozilla.org/mozilla-central/rev/855eb2e4c43d

Comment 10

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

Backout: https://hg.mozilla.org/mozilla-central/rev/505bafeafb66b0083ce1fca8eec2d061f1a5ebb7

Comment 13

[Molly Howell (she/her) (mostly inactive)]

Arthur, have you had a chance to take another look at this after the backout? We just had another report of the same issue (bug 1450963).

Comment 15

[Robert Strong (they/them - no direct email)]

No response to comment #13... resolving -> incomplete

Comment 16

[Georg Koppen]

(In reply to Robert Strong (Robert he/him) [:rstrong] (use needinfo to contact me) from comment #15)

No response to comment #13... resolving -> incomplete

The answer is actually: no, we did not have a chance yet to look at it again but it seems we (and I suspect other Firefox users affected by that) would still like to get that fixed.

Comment 17

[Robert Strong (they/them - no direct email)]

Georg, I just realized a bug I fixed also fixes this. We no longer change LD_LIBRARY_PATH as of bug 1434033 landing. Can you check if this is still an issue using latest nightly?

Comment 18

[Georg Koppen]

(In reply to Robert Strong (Robert he/him) [:rstrong] (use needinfo to contact me) from comment #17)

Georg, I just realized a bug I fixed also fixes this. We no longer change
LD_LIBRARY_PATH as of bug 1434033 landing. Can you check if this is still an
issue using latest nightly?

Hm, that's a bit tricky for us as we are on the ESR train and have a bunch of updater patches which we carry around and adapt the updater to our needs. What's the bug number/fix? Maybe we can backport something which we then could test...

Comment 19

[Robert Strong (they/them - no direct email)]

Bug 1434033
The patch is here
https://phabricator.services.mozilla.com/D20098
and landed here
https://hg.mozilla.org/mozilla-central/rev/ee53ed43d51d

Comment 20

[Robert Strong (they/them - no direct email)]

So, as long as you keep the updater alongside the shared libraries this bug should be fixed by bug 1434033. The updater no longer cares what LD_LIBRARY_PATH is set to as described in comment #2 and the AppendToLibPath function that the patch in this bug patches no longer exists. If there is still a problem after bug 1434033 then it can't be the same as this bug even if it is similar so I'm duping this the bug 1434033.

Comment 21

[Mark Smith [:mcs]]

(In reply to Robert Strong (Robert he/him) [:rstrong] (use needinfo to contact me) from comment #20)

So, as long as you keep the updater alongside the shared libraries this bug should be fixed by bug 1434033. The updater no longer cares what LD_LIBRARY_PATH is set to as described in comment #2 and the AppendToLibPath function that the patch in this bug patches no longer exists. If there is still a problem after bug 1434033 then it can't be the same as this bug even if it is similar so I'm duping this the bug 1434033.

Kathy Brade and I looked at this from a Tor Browser updater perspective. We did not test a backported patch, but Robert is correct that the specific issue covered by this bug is no longer an issue. For Tor Browser, because we define MAR_NSS on all platforms, we will need to do a little extra work for macOS and Windows when we move to the Firefox ESR 68 codebase. I opened a Trac ticket to track that task: https://trac.torproject.org/projects/tor/ticket/29818

Comment 22

[Robert Strong (they/them - no direct email)]

Hi Mark, I'd be interested in adding support for https://trac.torproject.org/projects/tor/ticket/29818 as well.