Note: There are a few cases of duplicates in user autocompletion which are being worked on.

Document that admins must run product once after installation

VERIFIED DUPLICATE of bug 41057

Status

SeaMonkey
Installer
P3
normal
VERIFIED DUPLICATE of bug 41057
17 years ago
8 years ago

People

(Reporter: Nick Garcia, Assigned: rudman)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

17 years ago
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

17 years ago
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

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

Comment 3

17 years ago
closing this bug as invalid.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → INVALID

Comment 4

17 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

Comment 5

17 years ago
Steve,
Please read my last comment.
Assignee: ssu → rudman
Keywords: nsbeta3

Updated

17 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 6

17 years ago
related/partly covered in bug 45863
(Assignee)

Comment 7

17 years ago
accepting
Status: NEW → ASSIGNED

Updated

17 years ago
QA Contact: gemal → gbush

Comment 8

17 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?

Comment 9

16 years ago
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

16 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

16 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

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

Comment 13

16 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

16 years ago
This bug covers documentation, so yes, WORKSFORME.

(I would rather we had "run as root once" but..)
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago16 years ago
Resolution: --- → WORKSFORME

Comment 15

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

16 years ago
verified
Status: RESOLVED → VERIFIED

Comment 17

15 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

15 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

15 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

15 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
Last Resolved: 16 years ago15 years ago
Resolution: --- → DUPLICATE

Comment 21

15 years ago
verified
Status: RESOLVED → VERIFIED

Comment 22

15 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

15 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
Last Resolved: 15 years ago15 years ago
Resolution: --- → DUPLICATE

Comment 24

15 years ago
And marking VERIFIED again.
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey

Updated

8 years ago
Blocks: 513190
You need to log in before you can comment on or make changes to this bug.