THE PROBLEM: When there is an existing PPP connection, Netscape seems to start normally. Otherwise Netscape freezes on startup (for about 2 minutes) when not connected via PPP. I guess it's waiting for a DNS lookup to time out. The root account has always had this problem -- but then why login as root all of the time? I've just kind of assumed at this point that if you had to login as root -- you're probably there on another agenda anyway ;-) To 'fix' the problem, I've found that if I delete my ~/.netscape directory, I can relaunch netscape -- no problem. This isn't a long term solution however, as I'd like to keep things that live there. But, this temporary fix does seem to work EVERY TIME. Strangely enough, I've found that if I create a new user account (say 'useradd foo'), and use foo's account foo doesn't seem to have the same problems that an existing account does. So the problem is exacerbated as the user configures the home environment. See Also: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=4851 http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=6614 http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=6851 http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=3471 THE SETUP: My setup consists of the following (as outlined in /etc/hosts@IntelBox) ::::::::::::::/etc/hosts::::::::::::: #Hosts file for DomainNameHERE.com #IP FQDN_ALIAS # 127.0.0.1 localhost # #Default Gateway 152.159.250.1 LANmodem.DomainNameHERE.com LANmodem # Hosts 152.159.250.5 PowerMacintosh.DomainNameHERE.com PowerMacintosh 152.159.250.3 stag.DomainNameHERE.com stag 152.159.250.6 Maria.DomainNameHERE.com Maria 152.159.250.39 IntelBox.DomainNameHERE.com IntelBox :::END::: ::::::::::::::/etc/hosts.conf::::::::::::: order hosts,bind multi on :::END::: More Info From the Gnome|System Menus|Utilities|System Info... Dialog: Distribution: Red Hat Linux Operating System: Linux Distribution Version: Red Hat Linux release 6.1 (Cartman) Operating System Version: #1 Mon Sep 27 10:40:35 EDT 1999 Operating System Release: 2.2.12-20 Processor Type: i686 Host Name: IntelBox.DomainNameHERE.com User Name: sean X Display Name: :0 System Status: 6:05am up 5:54, 2 users, load average: 0.00, 0.00, 0.04 The version of Netscape I'm using on IntelBox is: Netscape 4.7/Export, 15-Sept-99; (c) 1995-1998 Netscape Communications Corp. To create my PPP connection, one of the machines must tell the 3com lanmodem (via Netscape) to open it's connection to the remote ISP dialup. netstat -r on IntelBox produces: Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 152.159.250.0 * 255.255.255.0 U 0 0 0 eth0 127.0.0.0 * 255.0.0.0 U 0 0 0 lo default LANmodem.absolu 0.0.0.0 UG 0 0 0 eth0 Here's the clincher--I've experienced this problem in both RH 6.0 & now 6.1. This came shortly after I started using Enlightenment as a WM (now I use 0.16.3) as opposed to AfterStep. Anyway, The Problem isn't Enlightenment: I removed Enlightenment as a variable by switching to FVWM to check netscape there. The Problem could be Netscape: but I can't remove this as a variable -- I don't know of any other browsers. All my other DNS seem to work just fine. Gnome: Probably the only variable that I cannot presently remove; incedentlally I don't recall having this problem whent I was running RH 5.1 & afterstep. I originally upgraded from 6.0 to 6.1 to specifically alleviate this problem. IntelBox has been running just fine since November of 1999, with no sign of this glitch. So as a next step, I began by examining the directories and permissions of the files in the .netscape directory. [sean@IntelBox sean]# cd .netscape [sean@IntelBox sean]# ls -al total 284 drwxrwxr-x 5 sean sean 4096 Feb 7 01:37 . drwx------ 29 sean sean 4096 Feb 7 01:32 .. drwx------ 2 sean sean 4096 Feb 7 01:13 archive -rw------- 1 sean sean 11409 Feb 7 01:13 bookmarks.html drwx------ 2 sean sean 4096 Feb 7 01:15 cache -rw------- 1 sean sean 184320 Feb 7 01:14 cert7.db -rw------- 1 sean sean 16384 Feb 7 01:32 history.dat -rw------- 1 sean sean 16384 Feb 7 01:14 key3.db -rw-rw-r-- 1 sean sean 1062 Feb 7 01:32 liprefs.js -rw-rw-r-- 1 sean sean 0 Feb 7 01:13 nswrapper.copy_defs -rw-rw-r-- 1 sean sean 0 Feb 7 01:37 out -rw-rw-r-- 1 sean sean 505 Feb 7 01:32 plugin-list -rw-rw-r-- 1 sean sean 505 Feb 7 01:18 plugin-list.BAK -rw-rw-r-- 1 sean sean 3490 Feb 7 01:32 preferences.js -rw-rw-r-- 1 sean sean 741 Feb 7 01:14 registry -rw------- 1 sean sean 16384 Feb 7 01:32 secmodule.db drwxr-xr-x 3 sean sean 4096 Feb 7 01:13 xover-cache Eventually I found that by deleting the 'preferences.js' file in the .netscape dir I could get Netscape to start up: [sean@IntelBox sean]# rm preferences.js This is still NOT GOOD ENOUGH because it removes the Mail and News Preferences that I have set, as well as anything else. This made me believe that there was a setting within the preferences.js file that was causing Netscape to hang. So, I proceded to edit the file by removing half of the lines at a time. Two lines that are of interest: user_pref("browser.startup.license_accepted", "500 4.7"); # This Line verifies that the user accepted the liscense agreement. If you remove it a new filestructure is built in the ~/ dir. user_pref("news.directory", "/home/sean/"); # This is the offending line that keeps us from starting up. If you remove it you can start up once, but the line is added in that 'session'. THE SOLUTION: Create a new directory called 'nsnews' in the users home directory: [sean@IntelBox sean]# mkdir nsnews Then goto netscape's preferences here: Edit|Preferences|Mail & Newsgroups| Newsgroups Servers | Newsgroups directory and set the target directory to ~/nsnews This fixes the problem EVERY TIME for me (and even in the broken root account) so AFAICT it works. THE END: I'm really not sure why this works the way it does, but in all fairness It would seem proper that the information downloaded as 'News' has no business being strewn about in the users home dir. So a private directory makes sense. IMHO this is a netscape bug. NOT a RH Bug; Netscape should be installing this directory as a default (if it is really needed to prevent this kind of lockup). This may not be the best place for this dir, but it seems to do the job. Never mind the fact that this shouldn't ne an issue in the first place. Netscape should at least 'start' and THEN warn you about the missing directory. What is really strange is why this seems to happen in the first place. I don't recall doing anything to cause the problem, and nothing seems to show up in /var/log/ either. 'Sometimes a good idea today is better than a Great Idea Tomorrow'. Good luck! I hope this helps somebody, or at least makes someone think further about the problem. IT'S BEEN DRIVING ME NUTS FOR MONTHS.
Followup -- I have found that is you go back and try to re-edit the preferences, the problem comes back. So then, set all of your prefs on the first try -- otherwise things get stuck again.
Are you running a caching nameserver?
More info -- For whatever reason this problem seems to be reoccuring periodically. Here's how I'm attempting to fix this at this point. After setting your preferences in netscape, AND WHILE AT LEAST ONE BROWSER WINDOW IS OPEN, I did this... [sean@IntelBox sean]# su Password: ************ [root@IntelBox sean]# cd ~/.netscape [root@IntelBox .netscape]# chown root.root preferences.js [root@IntelBox .netscape]# chmod 604 preferences.js [root@IntelBox .netscape]# exit This prevents any user (including 'sean' and processes running under user 'sean' from modifying the 'preferences.js' file. 'sean' and his processes can still read the file however. Also for others who may be reading this ... I'm not using a caching nameserver. See the link '9173 Mail' on this page for more info. Cheers.. scooper
This is 100% repeatable. I see it on my laptop when the ethernet card is acting up. Netscape seems to make some trivial check for networking up, then goes ahead and does something on the net. iI hangs until this operation times out. You can verify this by turning a hung interface into a non-existant interface, and then netscape pops right up.
Having netscape hang connecting on a hung network interface until a timeout is normal behavior. I could never reproduce the original problem here.