Closed
Bug 49345
Opened 24 years ago
Closed 22 years ago
Document that admins must run product once after installation
Categories
(SeaMonkey :: Installer, defect, P3)
Tracking
(Not tracked)
People
(Reporter: ngarcia, Assigned: rudman)
References
Details
I just downloaded the 2000/08/16 Linux nightly build and installed it as root (since it wanted to go into /usr/local/). After the install I returned back to my normal user and tried to run it and it dumped core. If I run it as root however, it works fine.
try running once as root before running as a regular user. that should get you up and running. also, what version/flavor of linux are you running this on?
Reporter | ||
Comment 2•24 years ago
|
||
That worked, thanks! I'm running RedHat 6.2.
closing this bug as invalid.
Status: UNCONFIRMED → RESOLVED
Closed: 24 years ago
Resolution: --- → INVALID
Comment 4•24 years ago
|
||
We need to add this to the README. Reassigning to Steve Rudman. Steve, We need to document that after installation, users must run the product once as the same user who installed it (or a user with permissions in the target installation directory) to allow for autoregistration to occur. Autoregsitration causes a "component.reg" file to be written to the target installation directory. In cases where the user who runs the product for the first time is different from and/or does not have permissions to write to the target installation location, the product won't be able to autoregister and *will* core dump as this user did.
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
Summary: Install Problem → Document that admins must run product once after installation
Updated•24 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Updated•24 years ago
|
QA Contact: gemal → gbush
Comment 8•23 years ago
|
||
Surely dumping core is not the correct behavior if Mozilla cannot open those files for writing. Couldn't it pop up a helpful dialog or at least a brief message on the console and then exit cleanly?
I've run 0.9 as root several times but it still crashes when running it as a regular user: [pperalta@odyssey pperalta]$ /opt/mozilla/0.9/mozilla/mozilla /opt/mozilla/0.9/mozilla/run-mozilla.sh /opt/mozilla/0.9/mozilla/mozilla-bin MOZILLA_FIVE_HOME=/opt/mozilla/0.9/mozilla LD_LIBRARY_PATH=/opt/mozilla/0.9/mozilla:/opt/mozilla/0.9/mozilla/plugins LIBRARY_PATH=/opt/mozilla/0.9/mozilla:/opt/mozilla/0.9/mozilla/components SHLIB_PATH=/opt/mozilla/0.9/mozilla LIBPATH=/opt/mozilla/0.9/mozilla ADDON_PATH=/opt/mozilla/0.9/mozilla MOZ_PROGRAM=/opt/mozilla/0.9/mozilla/mozilla-bin MOZ_TOOLKIT= moz_debug=0 moz_debugger= /opt/mozilla/0.9/mozilla/run-mozilla.sh: line 72: 1379 Trace/breakpoint trap $prog ${1+"$@"} I installed it by downloading the tarball (as a normal user) and unzipping it in the /opt/mozilla/0.9 directory as root. The Help | About window tells me: Mozilla/5.0 (X11; U; Linux 2.2.16-22smp i686; en-US; rv:0.9) Gecko/20010505 and I'm running on Redhat 7.0, X 4.0.2, Gnome/Sawfish
Comment 10•23 years ago
|
||
The need to run as root is a bug the furst time is a bug. Please fix the bug. Documenting it is not a solution.
Comment 11•23 years ago
|
||
It might be a bug, but the solution involves either making something world-writeable, or setuid, which I don't know about. However, why isnt this bug # here mentioned in the 0.9.6 relnotes? Also, see bug 88822 and bug 42184
Comment 12•22 years ago
|
||
*** Bug 123785 has been marked as a duplicate of this bug. ***
Comment 13•22 years ago
|
||
Isn't this fixed by the following comment at: http://www.mozilla.org/releases/mozilla0.9.8/#install Multi-user installs: To install Mozilla for multiple users on Unix, install as normal, then create the following script in your Mozilla directory, make it executable (chmod u+x <scriptname>), and run it as root. #!/bin/sh dist_bin=`dirname $0` MOZILLA_FIVE_HOME=$dist_bin LD_LIBRARY_PATH=$dist_bin export MOZILLA_FIVE_HOME LD_LIBRARY_PATH $dist_bin/regxpcom $dist_bin/regchrome touch $dist_bin/chrome/user-skins.rdf $dist_bin/chrome/user-locales.rdf You should then be able to run that installation of Mozilla as any user who has permissions to access it.
Comment 14•22 years ago
|
||
This bug covers documentation, so yes, WORKSFORME. (I would rather we had "run as root once" but..)
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 22 years ago
Resolution: --- → WORKSFORME
Comment 15•22 years ago
|
||
Why isn't the multiuser option default on Unix? It makes no sense to think of a single user Unix machine. Just include the script in the nightly builds and make sure the installer runs after installation. Just my 0.02$
Comment 17•22 years ago
|
||
Agree with Sven and Daniel, to wit: all unix systems should be treated as multiuser, and mozilla should not simply coredump when components.reg cannot be created. FWIW, this still happens with mozilla 1.0 on sparc-solaris7.
Comment 18•22 years ago
|
||
Doesn't WORKFORME. Only the "first run" user can run it, others just get a mozilla.bin sleeping eternally. I even ran: #! /bin/sh # # J$ - As per <http://bugzilla.mozilla.org/show_bug.cgi?id=49345> # dist_bin=`dirname $0` MOZILLA_FIVE_HOME=$dist_bin LD_LIBRARY_PATH=$dist_bin export MOZILLA_FIVE_HOME LD_LIBRARY_PATH $dist_bin/regxpcom $dist_bin/regchrome touch $dist_bin/chrome/user-skins.rdf $dist_bin/chrome/user-locales.rdf
Status: VERIFIED → REOPENED
Resolution: WORKSFORME → ---
Comment 19•22 years ago
|
||
This is the sleep-loop Mozilla 1.0 gets into, when invoked by any user other than the one that ran it first after install, with write priviliges to the install dir: 15407: sigprocmask(SIG_SETMASK, 0xFE60BE28, 0x00000000) = 0 15407: lwp_sema_post(0xFD581E78) = 0 15407: lwp_sema_wait(0xFD581E78) = 0 15407: sigprocmask(SIG_SETMASK, 0xFEAF9748, 0x00000000) = 0 15407: setcontext(0xFE60BA10) 15407: sigprocmask(SIG_BLOCK, 0xFEAEE3F0, 0x00000000) = 0 15407: sigprocmask(SIG_UNBLOCK, 0xFEAEE3F0, 0x00000000) = 0 15407: poll(0x00156C78, 3, -1) = 1 15407: write(5, "FA", 1) = 1 15407: lwp_sema_post(0xFEAEE400) = 0 15407: lwp_sema_wait(0xFEAEE400) = 0 15407: sigprocmask(SIG_BLOCK, 0xFEAEE3F0, 0x00000000) = 0 15407: setitimer(ITIMER_REAL, 0xFE60BCB8, 0x00000000) = 0 15407: sigprocmask(SIG_UNBLOCK, 0xFEAEE3F0, 0x00000000) = 0 15407: lwp_sema_post(0xFD581E78) = 0 15407: lwp_sema_wait(0xFD581E78) = 0 15407: lwp_mutex_wakeup(0xFEAF3F88) = 0 15407: lwp_mutex_lock(0xFEAF3F88) = 0 15407: lwp_sema_post(0xFEAEE400) = 0 15407: lwp_sema_wait(0xFEAEE400) = 0 15407: sigprocmask(SIG_BLOCK, 0xFEAEE3F0, 0x00000000) = 0 15407: setitimer(ITIMER_REAL, 0xFE60BCB8, 0x00000000) = 0 15407: sigprocmask(SIG_UNBLOCK, 0xFEAEE3F0, 0x00000000) = 0 15407: read(4, "FA", 1) = 1 15407: ioctl(6, FIONREAD, 0xFFBEF28C) = 0 15407: poll(0x00156C78, 3, -1) (sleeping...) 15407: signotifywait() (sleeping...) 15407: poll(0xFDBE1990, 1, 35000) (sleeping...) 15407: lwp_sema_wait(0xFD581E78) (sleeping...) 15407: lwp_cond_wait(0xFEAF3F78, 0xFEAF3F88, 0xFDA15C38) (sleeping...) 15407: door_return(0x00000000, 0, 0x00000000, 0) (sleeping...) 15407: lwp_sema_wait(0xFEAEE400) (sleeping...) 15407: Received signal #14, SIGALRM, in lwp_sema_wait() [caught] 15407: lwp_sema_wait(0xFEAEE400) Err#91 ERESTART
Comment 20•22 years ago
|
||
Please read the Summary: "Document ..." This has been documented. It is not WORKSFORME, this is FIXED and has been resolved in other bugs like bug 41057 or bug 74574. This is a duplicate, marking as such. Please let this bug rest in peace and follow the discussion in the likes of bug 42184 if you feel that multiuser installation should be the default. *** This bug has been marked as a duplicate of 41057 ***
Status: REOPENED → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → DUPLICATE
Comment 22•22 years ago
|
||
It is *not* FIXED, it does *not* WORKFORME, and it's *not* a matter following the instructions in <http://www.mozilla.org/releases/mozilla1.0/> contains to get a multi-user install. I *did* take all the steps, I *did* create all the documents. It. Does. Not. Work. No core dumps (which is what you get if you do not perform the extra "regxpcom" and "regchrome" steps. Just an eternally sleeping mozilla.bin. I think this is getting annoying. I'm not making this up, you know, and will do what I can to help crack this thing. Going into denial will certainly not resolve the issue. It's real. You can of course decide not to fix it, and I'll inform my users and move on. Just don't pretend there's no problem. There is.
Status: VERIFIED → REOPENED
Resolution: DUPLICATE → ---
Comment 23•22 years ago
|
||
Jeroen, nobody is in denial here. Nobody said this was WORKSFORME or FIXED. This bug was marked a *DUPLICATE*! You should only reopen it if you disagree with this being a duplicate of the other bug. Multiuser install has been working for a lot of people with the instructions in the release notes. If it suddenly stopped working for you, please file a new bug and do not reopen a *two year old* duplicate. If you are passionate about this issue (rightly so, I think this has been a serious shortcoming for quite a while), join the discussion in bug 90879, bug 42184 or bug 51677. Do not reopen the parent of this bug, bug 41057. I repeat: These bugs are about _documentation_. The described steps should work, if they don't, file a new bug. Thank you. Sorry for sounding a bit harsh, but reopening verified bugs because of offtopic problems and crying bloody murder in the process is not going to win you much sympathy (much less solve your problem). *** This bug has been marked as a duplicate of 41057 ***
Status: REOPENED → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → DUPLICATE
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•