updater failing on Linux (cannot find libraries)
Categories
(Toolkit :: Application Update, defect, P2)
Tracking
()
People
(Reporter: arthur, Assigned: arthur)
References
(Blocks 1 open bug)
Details
(Whiteboard: [tor 18900])
Attachments
(1 file)
2.07 KB,
patch
|
robert.strong.bugs
:
review+
|
Details | Diff | Splinter Review |
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).
Updated•6 years ago
|
Comment 1•6 years ago
|
||
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?
Assignee | ||
Comment 2•6 years 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.)
Comment 3•6 years ago
|
||
That makes sense and thank you!
Assignee | ||
Updated•6 years ago
|
Assignee | ||
Comment 4•6 years ago
|
||
Assignee | ||
Comment 5•6 years ago
|
||
https://treeherder.mozilla.org/#/jobs?repo=try&revision=853310922146223920a1cd7ed3817ad3258c18e4
Comment 6•6 years ago
|
||
Comment on attachment 8950475 [details] [diff] [review] 0001-Bug-1434666-Avoid-path-aliasing-in-AppendToLibPath.patch Nicely done and thanks!
Pushed by apavel@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/855eb2e4c43d Avoid path aliasing in AppendToLibPath r=rstrong
Comment 9•6 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/855eb2e4c43d
Comment 10•6 years ago
|
||
Backout: https://hg.mozilla.org/mozilla-central/rev/505bafeafb66b0083ce1fca8eec2d061f1a5ebb7
Comment 13•6 years ago
|
||
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•5 years ago
|
||
No response to comment #13... resolving -> incomplete
Comment 16•5 years 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.
Updated•5 years ago
|
Comment 17•5 years ago
|
||
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•5 years 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...
Comment 19•5 years ago
|
||
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•5 years ago
|
||
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•5 years ago
|
||
(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•5 years ago
|
||
Hi Mark, I'd be interested in adding support for https://trac.torproject.org/projects/tor/ticket/29818 as well.
Description
•