Last Comment Bug 49345 - Document that admins must run product once after installation
: Document that admins must run product once after installation
Status: VERIFIED DUPLICATE of bug 41057
:
Product: SeaMonkey
Classification: Client Software
Component: Installer (show other bugs)
: Trunk
: x86 Linux
: P3 normal with 1 vote (vote)
: ---
Assigned To: rudman
: Grace Bush
:
Mentors:
: 123785 (view as bug list)
Depends on:
Blocks: 513190
  Show dependency treegraph
 
Reported: 2000-08-17 11:03 PDT by Nick Garcia
Modified: 2009-08-27 23:23 PDT (History)
9 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments

Description Nick Garcia 2000-08-17 11:03:53 PDT
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 2000-08-17 11:11:06 PDT
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 2000-08-17 11:23:36 PDT
That worked, thanks!  I'm running RedHat 6.2.
Comment 3 Sean Su 2000-08-17 11:39:55 PDT
closing this bug as invalid.
Comment 4 Samir Gehani 2000-08-17 11:46:58 PDT
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 2000-08-17 11:47:33 PDT
Steve,
Please read my last comment.
Comment 6 R.K.Aa. 2000-08-17 12:05:36 PDT
related/partly covered in bug 45863
Comment 7 rudman 2000-08-17 13:26:47 PDT
accepting
Comment 8 Daniel J. Peng 2001-03-05 19:14:52 PST
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 2001-05-08 14:37:54 PDT
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 2001-10-17 08:18:21 PDT
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 2001-12-13 08:44:53 PST
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 2002-02-06 06:38:59 PST
*** Bug 123785 has been marked as a duplicate of this bug. ***
Comment 13 Diego Biurrun 2002-02-17 06:29:52 PST
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 2002-02-18 01:25:29 PST
This bug covers documentation, so yes, WORKSFORME.

(I would rather we had "run as root once" but..)
Comment 15 Sven Esbjerg 2002-02-18 01:48:11 PST
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 2002-02-18 14:40:11 PST
verified
Comment 17 Noah Friedman 2002-06-13 15:21:34 PDT
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 2002-06-22 01:08:29 PDT
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 2002-06-23 08:11:56 PDT
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 2002-06-25 10:36:43 PDT
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 2002-06-30 17:55:44 PDT
verified
Comment 22 Jeroen Scheerder 2002-07-01 01:25:24 PDT
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 2002-07-01 02:59:25 PDT
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 2002-07-01 03:36:52 PDT
And marking VERIFIED again.

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