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)

x86
Linux
defect

Tracking

(Not tracked)

VERIFIED DUPLICATE of bug 41057

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?
That worked, thanks!  I'm running RedHat 6.2.
closing this bug as invalid.
Status: UNCONFIRMED → RESOLVED
Closed: 24 years ago
Resolution: --- → INVALID
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
Steve,
Please read my last comment.
Assignee: ssu → rudman
Keywords: nsbeta3
Status: UNCONFIRMED → NEW
Ever confirmed: true
related/partly covered in bug 45863
accepting
Status: NEW → ASSIGNED
QA Contact: gemal → gbush
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
  
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.
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
*** Bug 123785 has been marked as a duplicate of this bug. ***
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.
This bug covers documentation, so yes, WORKSFORME.

(I would rather we had "run as root once" but..)
Status: ASSIGNED → RESOLVED
Closed: 24 years ago22 years ago
Resolution: --- → WORKSFORME
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$
verified
Status: RESOLVED → VERIFIED
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.
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 → ---
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
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 ago22 years ago
Resolution: --- → DUPLICATE
verified
Status: RESOLVED → VERIFIED
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 → ---
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 ago22 years ago
Resolution: --- → DUPLICATE
And marking VERIFIED again.
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
Blocks: 513190
You need to log in before you can comment on or make changes to this bug.