Problems With Getty And X On Runlevel Switch [Was: The Future Of CentOS]

Home » CentOS » Problems With Getty And X On Runlevel Switch [Was: The Future Of CentOS]
CentOS 16 Comments

Thanks for drawing my attention to that bug. I encountered it the other day after switching from runlevel 5 to 3 (and back again) on a CentOS
6.6 machine.

The purpose of the runlevel switch was to restart gdm. Is there a better way?

16 thoughts on - Problems With Getty And X On Runlevel Switch [Was: The Future Of CentOS]

  • ISTR an alt-backspace to restart X (been a _long_ time)? Of course with the apparent conflicts in underlying script/config (tries to spawn gettys on tty1-6 expecting X to start on tty7 but X starts on tty1) I
    don’t know if this would work any better.

    My work around is a dummy user logged in on the first session (tty1) and use System->Log-out->Switch User from the panel to run real users on second and subsequent sessions for other users (all me). The subsequent sessions will start on tty7.

    Nice to know I’m not the only one that tries to use system facilities the way they were intended to work and has problems. Maybe if you touch the bug report so they know I’m not the only one the folks will look and elevate to RH bug just like they used to do? I was surprised that
    “crash” didn’t get any attention.


  • The easy way to restart gdm is when you are on the login screen itself or the desktop simply press Ctrl-Alt-Backspace. This works for Upstart in CentOS 6.x but will not work for CentOS 7.x which uses Systemd. The service command does not work for gdm. However, logging out of the desktop will restart gdm. It works for the graphical login exactly like the gettys in a TTY environment.

  • Am 08.04.2015 um 13:08 schrieb David Both :

    I remember that this “shortcut” is an X11 server feature
    (it kills the process!) that can be en/disabled.

  • Thanks for the suggestion.

    Logging out and keying ctrl-alt-backspace both restart X, certainly, but I’m not so sure about gdm. I’m not at a CentOS 6 machine right now so I
    can’t confirm one way or the other.

  • Since CentOS 6 uses Upstart as its init system, and GDM is run from an Upstart service (and not a SysV init script), you can use the upstart tools to restart GDM. It’s actually run from the ‘prefdm’ service
    (because it could also run kdm or xdm).

    # initctl restart prefdm prefdm start/running, process 29141

  • Not according to the output of pstree. See the following snippet:

    │ │ ├─gdm-session-wor─┬─gnome-session─┬─bluetoo+
    │ │ │ │ ├─compiz─+
    │ │ │ │ │ +
    │ │ │ │ ├─gdu-not+
    │ │ │ │ ├─gnome-p+
    │ │ │ │ ├─gpk-upd+
    │ │ │ │ ├─nautilu+
    │ │ │ │ ├─polkit-+
    │ │ │ │ ├─python
    │ │ │ │ ├─restore+
    │ │ │ │ └─{gnome-+
    │ │ │ └─{gdm-session-wo}
    │ │ └─{gdm-simple-sla}
    │ └─{gdm-binary}

    Xorg is in fact a sub-sub-process of gdm-binary.

    While logged into a GNOME session, I ran the pgrep command as follows:

    $ pgrep -fl gdm
    1583 /usr/sbin/gdm-binary -nodaemon
    1619 /usr/libexec/gdm-simple-slave –display-id /org/gnome/DisplayManager/Display1
    1622 /usr/bin/Xorg :0 -br -verbose -audit 4 -auth /var/run/gdm/auth-for-gdm-EcVz3c/database -nolisten tcp vt1
    1801 pam: gdm-password

    I restarted X using ctrl-alt-backspace, logged back in and ran the command again:

    $ pgrep -fl gdm
    1583 /usr/sbin/gdm-binary -nodaemon
    1619 /usr/libexec/gdm-simple-slave –display-id /org/gnome/DisplayManager/Display1
    1622 /usr/bin/Xorg :0 -br -verbose -audit 4 -auth /var/run/gdm/auth-for-gdm-EcVz3c/database -nolisten tcp vt1
    1801 pam: gdm-password

    X has indeed restarted, but the gdm-related processes have not.


  • As a follow-up, running the command ‘initctl restart prefdm’ as suggested by Johnathan did the trick:

    $ pgrep -fl gdm
    5728 /usr/sbin/gdm-binary -nodaemon
    5744 /usr/libexec/gdm-simple-slave –display-id
    5747 /usr/bin/Xorg :0 -br -verbose -audit 4 -auth
    /var/run/gdm/auth-for-gdm-QmU6b6/database -nolisten tcp vt1
    5804 pam: gdm-password


  • Yup. In fact, it’s possible to run GDM without X at all, such as when you’re running display manager with XDMCP.

  • Am 08.04.2015 um 21:16 schrieb Liam O’Toole :

    oh, i had something in mind that obviously is obsolete, okay :-)

  • While only vaguely related to this topic, does anyone else find that CentOS6 desktop stability is lacking? Or did we just never notice because no monitoring was in place pre-C6?

    I’m refering to abrtd which is sending out a susprising amount of notifications about crashing desktop components like nautilus gthumb gnome-panel gvfsd-trash gvfsd-metadata gnome-settings-daemon, to name just a few.

  • I’ve seen this many times, predominately when using ksnapshot to get an image and display it and with nautilus. Gave up trying to get a report via the abort daemon stuff into someplace it might count as I don’t have an RH account.

    Initially I thought it would improve as folks with subscriptions reported it, but that seems to have not happened.

    Fortunately, it’s only a minor irritation for me.


  • I don’t see this in our ~1000 RHEL6.6 student workstations we run. Assuming the desktop packages are bug-identical in CentOS, I’d assume to see the same amount of errors.

    I suspect you might want to investigate the abrt errors to see if there isn’t something amiss in your environment.

  • The only one I was seeing was pulseaudio crashing in the host whenever I started up a virtual machine. I say “was seeing” because I’ve since shut off the abrtd service.