From Martin K. Petersen on Tue, 12 Oct 1999
Sorry about the delay. I've been attending Linux Kongress the past week.
The fact that the version of GNOME gdm that shipped with Red Hat 6.x can't gracefully handle (clean up after) an inadvertant shutdown or other mishap is very disappointing.
Well, contrary to common belief X display management isn't trivial at all. Since gdm is a complete redesign/rewrite of xdm, it is bound to have problems. I have never tried to conceal the fact that gdm has issues. It even says so on the web page.
That being said, gdm works ok for local display management, provided the X server is relatively well behaved (i.e. not buggy).
The fact that the version of GNOME gdm that shipped with Red Hat 6.x can't gracefully handle (clean up after) an inadvertant shutdown
Yes it can. You're speculating.
I find it disappointing that a person like you, who has been in the Linux business for several years, resorts to spreading FUD. Don't answer questions, if you don't know the answer.
The right answer here, like in 99% of all other cases concerning system daemons, would be to consult the syslog.
I believe I did consult the syslogs. I remember that I did have to remove some sort of lock file or something before I could get gdm working again (but I don't remember the details).
I did NOT see this question listed in their FAQ (which surprises me, since I would think that this would be a very commonly encountered problem among RH6/GNOME users). However, I did find a link to a bug tracking system. From there I searched for messages related to our "murdered mysteriously" problem. There was some indication that Martin K. Petersen is the contact for gdm and that he posted patches to resolve that (and several other) gdm issues.
The "murdered mysteriously" message is a non-critical warning, not a failure. Thus it hasn't and never will be "fixed". Neither have I posted any patches to resolve it.
The message indicates that something killed the master gdm process or something left Xlib in a state which it couldn't handle gracefully. I.e. gdm was forced to about without cleaning up. However, this doesn't affect subsequent startups in any way.
/Martin
This suggests that a simple [Ctrl][Alt][BackSpace] or a 'telinit q' command should restore 'gdm' to functioning. Or is there some sort of state preserved by Xlib in the filesystem?
I'm sorry if my message offended you. I was frustrated when I first encounted this error message (in front of a class full of new Linux students, in fact) and I seem to recall that the problem persisted through a reboot, and required some fussing with lockfiles or unix domain socket entries, or something.
I was also frustrated when I got the question for my column.
Since I don't run GNOME on my home systems or my workstation I don't have an easy way to attempt to reproduce the problem myself. The user didn't provide me with much info either.
(Thus I am forced to speculate: frequently and for many of my answers. I try to let people know when I'm guessing and when I'm speaking from first hand experience. Sometimes I fail).
I have seen Red Hat 6.0 systems FAIL to bring up gdm in a persistent way. I've seen the message "gdm murdered mysteriously" associated with this failure. It might not be a failure of gdm's --- but the gdm error message is certainly occurring at about the same time.
Anyway, hopefully GNOME will be more stable in Red Hat 6.2 or 6.3. Overall I think Red Hat Inc has been pushing it on to too many desktops a little too quickly.
1 | 2 | 3 | 5 | |||||
5 | 6 | 7 | 8 | 9 | ||||
10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 |
28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 |
37 | 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45 |
46 | 47 | 48 | 49 | 50 | 51 | 52 | 53 | 54 |
55 | 56 | 57 |