updater failing on Linux (cannot find libraries)

RESOLVED DUPLICATE of bug 1434033

Status

()

defect
P2
normal
RESOLVED DUPLICATE of bug 1434033
a year ago
a month ago

People

(Reporter: arthur, Assigned: arthur)

Tracking

(Blocks 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [tor 18900])

Attachments

(1 attachment)

(Assignee)

Description

a year ago
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).
Flags: needinfo?(robert.strong.bugs)
Priority: -- → P2
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?
Flags: needinfo?(robert.strong.bugs) → needinfo?(arthuredelstein)
(Assignee)

Comment 2

a year ago
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.)
Flags: needinfo?(arthuredelstein)
(Assignee)

Updated

a year ago
Assignee: nobody → arthuredelstein
Comment on attachment 8950475 [details] [diff] [review]
0001-Bug-1434666-Avoid-path-aliasing-in-AppendToLibPath.patch

Nicely done and thanks!
Attachment #8950475 - Flags: review?(robert.strong.bugs) → review+
(Assignee)

Comment 7

a year ago
Thanks for the review!
Keywords: checkin-needed

Comment 8

a year ago
Pushed by apavel@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/855eb2e4c43d
Avoid path aliasing in AppendToLibPath r=rstrong
Keywords: checkin-needed

Comment 9

a year ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/855eb2e4c43d
Status: NEW → RESOLVED
Last Resolved: a year ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla60
Depends on: 1440783
(Assignee)

Updated

a year ago
Depends on: 1441449
Backout: https://hg.mozilla.org/mozilla-central/rev/505bafeafb66b0083ce1fca8eec2d061f1a5ebb7
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Target Milestone: mozilla60 → ---
Duplicate of this bug: 1450963
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).
Flags: needinfo?(arthuredelstein)
Duplicate of this bug: 1348604

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

Status: REOPENED → RESOLVED
Last Resolved: a year agoa month ago
Resolution: --- → INCOMPLETE

Comment 16

a month ago

(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.

Status: RESOLVED → REOPENED
Resolution: INCOMPLETE → ---

Updated

a month ago
Flags: needinfo?(arthur)

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?

Flags: needinfo?(gk)

Comment 18

a month ago

(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...

Flags: needinfo?(gk)

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.

Status: REOPENED → RESOLVED
Last Resolved: a month agoa month ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1434033

(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

You need to log in before you can comment on or make changes to this bug.