49345 - Document that admins must run product once after installation

Status: VERIFIED DUPLICATE of bug 41057

(SeaMonkey :: Installer, defect, P3)

Description

[Nick Garcia]

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.

Comment 1

[Sean Su]

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?

Comment 2

[Nick Garcia]

That worked, thanks!  I'm running RedHat 6.2.

Comment 3

[Sean Su]

closing this bug as invalid.

Comment 4

[Samir Gehani]

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.

Comment 5

[Samir Gehani]

Steve,
Please read my last comment.

Comment 6

[R.K.Aa.]

related/partly covered in bug 45863

Comment 7

[rudman]

accepting

Comment 8

[Daniel J. Peng]

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?

Comment 9

[patrick]

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

[David M. Cooke]

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

[Christian Reis]

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

[André Dahlqvist]

*** Bug 123785 has been marked as a duplicate of this bug. ***

Comment 13

[Diego Biurrun]

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

[Christian Reis]

This bug covers documentation, so yes, WORKSFORME.

(I would rather we had "run as root once" but..)

Comment 15

[Sven Esbjerg]

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 16

[Grace Bush]

verified

Comment 17

[Noah Friedman]

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

[Jeroen Scheerder]

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

Comment 19

[Jeroen Scheerder]

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

[Diego Biurrun]

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 ***

Comment 21

[Grace Bush]

verified

Comment 22

[Jeroen Scheerder]

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.

Comment 23

[Diego Biurrun]

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 ***

Comment 24

[Diego Biurrun]

And marking VERIFIED again.