After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 493942 - The shutdown option restarts the xorg server
The shutdown option restarts the xorg server
Status: RESOLVED DUPLICATE of bug 471479
Product: gdm
Classification: Core
Component: general
2.20.x
Other All
: Normal minor
: ---
Assigned To: GDM maintainers
GDM maintainers
Depends on:
Blocks:
 
 
Reported: 2007-11-05 22:51 UTC by Ken Moffat
Modified: 2007-11-05 23:07 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Ken Moffat 2007-11-05 22:51:28 UTC
Please describe the problem:
 With 2.20.1 (and corresponding 2.20 versions of everything else I built - this isn't a full gnome desktop), the shutdown process is unpleasant:
1. log out of desktop (in my case, I'm running icewm if it makes a difference)
2. wait for X to reload, and then select shutdown; confirm this.
3. X reloads again after the system log shows the change to runlevel 0.
 This means my initscript to shut down gdm gets called before gdm has been reborn (X is still loading itself) so gdm-stop is called before the gdm.pid has been recreated, and thus has nothing to do.
4. Shortly after this, gdm appears, then vanishes when all processes are sent the TERM signal.

Steps to reproduce:
1. choose the normal 'shutdwon' option and confirm it.
 (that's all!)


Actual results:
 As described, X restarts again, gdm reappears, then everything shuts down.

Expected results:
 System display reverts to tty1, with message that it is shutting down, then shuts down the bootscripts in an orderly manner with status reports. The orderly shutdown is indeed happening, but obscured because X occupies the screen.

Does this happen every time?
 With 2.20.1 the problem happens every time.

Other information:
 Systems affected are x86_64 (64-bit) and ppc, both running a recently built desktop using xorg-7.3 with xserver-1.4.0.

 Reverting to gdm-2.18.4 on an otherwise 2.20 system solved the problem.

 I was recommended to try debugging, in case it was the xserver segfaulting.  I can't see any evidence of a segfault, the relevant messages from the log (pruned to only show the change of runlevel through to gdm restarting) are:
Nov  3 02:46:53 bluesbreaker shutdown[2824]: shutting down for system halt
Nov  3 02:46:54 bluesbreaker init: Switching to runlevel: 0
Nov  3 02:46:54 bluesbreaker gdm-binary[2585]: DEBUG: gdm_final_cleanup 
Nov  3 02:46:54 bluesbreaker gdm-binary[2585]: DEBUG: gdm_display_unmanage: Stopping :0 (slave pid: 0) 
Nov  3 02:46:54 bluesbreaker gdm-binary[2585]: DEBUG: gdm_display_unmanage: Display stopped 
Nov  3 02:46:54 bluesbreaker gdm-binary[2585]: DEBUG: Attempting to parse key string: xdmcp/Enable=false 
Nov  3 02:46:54 bluesbreaker gdm-binary[2585]: DEBUG: Attempting to parse key string: daemon/ServAuthDir=/var/lib/gdm 
Nov  3 02:46:54 bluesbreaker gdm-binary[2585]: DEBUG: gdm_child_action: In remanage 
Nov  3 02:46:54 bluesbreaker gdm-binary[2585]: DEBUG: gdm_display_manage: Managing :0  
Nov  3 02:46:54 bluesbreaker gdm-binary[2585]: DEBUG: loop check: last_start 1194054885, last_loop 1194054885, now: 1194058014, retry_count: 1 
Nov  3 02:46:54 bluesbreaker gdm-binary[2585]: DEBUG: Resetting counts for loop of death detection, 90 seconds elapsed since loop started or session lasted more then 30 seconds. 
Nov  3 02:46:54 bluesbreaker gdm-binary[2585]: DEBUG: Forking slave process  
Nov  3 02:46:54 bluesbreaker gdm-binary[2847]: CRITICAL: gdm_connection_close: assertion `conn != NULL' failed 
Nov  3 02:46:54 bluesbreaker last message repeated 2 times
Nov  3 02:46:54 bluesbreaker gdm-binary[2847]: DEBUG: Attempting to parse key string: xdmcp/PingIntervalSeconds=15 
Nov  3 02:46:54 bluesbreaker gdm-binary[2585]: DEBUG: gdm_display_manage: Forked slave: 2847  
Nov  3 02:46:54 bluesbreaker gdm-binary[2585]: DEBUG: mainloop_sig_callback: Got signal 17 
Nov  3 02:46:54 bluesbreaker gdm-binary[2847]: DEBUG: gdm_slave_start: Starting slave process for :0
Comment 1 Brian Cameron 2007-11-05 23:07:44 UTC
This bug has already been reported, marking this as a duplicate.

*** This bug has been marked as a duplicate of 471479 ***