hacking on GDM

In August of 2011, I got annoyed enough with the lack of features in the latest GDM (version 3.0.4) to actually investigate the possibility of hacking the source to work around some annoying issues. In particular these are: Previous versions of gdm were much more cooperative and configurable. I won't disguise my newly found animosity towards gnome. With the advent of gnome 3, it has risen to the top of my list of most despised elements of linux software.

The most insulting thing I can think to say is that they have taken on a microsoft like attitude of "we know what is best for you" along with "why would you want to do things any other way". This kind of arrogance could be endured if Gnome 3 didn't suck so badly.

Getting the source

This is easy enough, I go to f15/updates/SRPMS and copy gdm-3.0.4-1.fc15.src.rpm into my rpmbuild/SRPMS directory and do rpm -i gdm-3.0.4-1.fc15.src.rpm. This extracts the components of the source rpm into the directory rpmbuild/SOURCES and I go into there and find gdm-3.0.4.tar.bz2. There are also a number of patch files and other rubbish that I am choosing to ignore for now.

The -j switch to tar copes with .bz2 compressed files.

What files are involved

The gdm rpm provides much more than the binary executable /usr/sbin/gdm. A list of the component files can be found here.

systemd

A sensible person would be curious how gdm was launched, what processes are involved, and what other subsystems (such as gnome-session) might be involved.

It turns out that all of this has changed drastically with Fedora 15. No longer does /sbin/init run as PID 1, but a new thing called systemd has that honor. Good old service and chkconfig still work in a sort of compatibility mode. The file /etc/inittab is now a relic that claims to set the default run level, but in fact does not. For that matter run levels are now obsolete (but the illusion of run levels is being loosely maintained to avoid frightening the innocent).

Systemd now deals with units. Each unit has its own configuration file (and a type). There are seven types (a service unit pertains to some service such as httpd, a target unit is used to group units and provide the run level illusion). The files controlling all of this are in /etc/systemd.

The systemctl utility is used to inspect and control the state of systemd managed services.

The file /etc/systemd/default.target is the target unit launched by systemd on boot. Also take a look at /lib/systemd

On my system /etc/systemd/system, the file default.target is a link to /lib/systemd/system/runlevel5.target which is a link to /lib/systemd/system/graphical.target

Within the directory /lib/systemd/system there is a directory graphical.target.wants within which is one file (a link) as follows: display-manager.service -> /lib/systemd/system/display-manager.service

It is this file that launches gdm as follows:

ExecStart=/etc/X11/prefdm -nodaemon
This is a script which examines /etc/sysconfig/desktop and then in general launches /usr/sbin/gdm (though it could launch kdm, wdm, xdm, or a display manager given by an absolute path).

Note that /usr/sbin/gdm is a script that launches /usr/sbin/gdm-binary after setting the LANG environment variable.

Process structure

With nobody logged in, I see the following processes via ps:

PID 1 = /bin/systemd
PID 1 --> PID 2053 = /usr/sbin/gdm-binary nodaemon
PID 2053 --> PID 14817 = /usr/libexec/gdm-simple-slave --display-id /org/gnome/DisplayManager/Display1
PID 14817 --> PID 14819 = /usr/bin/Xorg :0 -br -verbose -auth /var/run/gdm/auth-for-gdm-u1YcAA/database -nolisten tcp
PID 14817 --> PID 14840 = /usr/bin/gnome-session --session gdm --autostart=/usr/share/gdm/autostart/LoginWindow/
PID 14840 --> PID 14849 = /usr/libexec/gnome-settings-daemon
PID 14840 --> PID 14869 = metacity
PID 14840 --> PID 14871 = gnome-power-manager
PID 14840 --> PID 14874 = /usr/libexec/polkit-gnome-authentication-agent-1
PID 14840 --> PID 14875 = /usr/libexec/gdm-simple-greeter
PID 14817 --> PID 14896 = pam: gdm-password

Once I am logged in at the console, what I see via ps is as follows:

PID 1 = /bin/systemd
PID 1 --> PID 2053 = /usr/sbin/gdm-binary nodaemon
PID 2053 --> PID 14817 = /usr/libexec/gdm-simple-slave --display-id /org/gnome/DisplayManager/Display1
PID 14817 --> PID 14819 = /usr/bin/Xorg :0 -br -verbose -auth /var/run/gdm/auth-for-gdm-u1YcAA/database -nolisten tcp
PID 14817 --> PID 14896 = pam: gdm-password
PID 1 --> PID 15574 = /usr/bin/Terminal
PID 15574 --> PID 15575 gnome-pty-helper
PID 15574 --> PID 15576 bash
PID 15574 --> PID 15636 bash
Notice that all the children of Xorg when I was not logged in (including gnome-session) go away once I log in.

When I am logged in remotely via ssh, I see:

PID 1 = /bin/systemd
PID 1 --> PID 2053 = /usr/sbin/gdm-binary nodaemon
PID 2053 --> PID 14817 = /usr/libexec/gdm-simple-slave --display-id /org/gnome/DisplayManager/Display1
PID 14817 --> PID 14819 = /usr/bin/Xorg :0 -br -verbose -auth /var/run/gdm/auth-for-gdm-u1YcAA/database -nolisten tcp
PID 14817 --> PID 14840 = /usr/bin/gnome-session --session gdm --autostart=/usr/share/gdm/autostart/LoginWindow/
PID 14840 --> PID 14849 = /usr/libexec/gnome-settings-daemon
PID 14840 --> PID 14869 = metacity
PID 14840 --> PID 14871 = gnome-power-manager
PID 14840 --> PID 14874 = /usr/libexec/polkit-gnome-authentication-agent-1
PID 14840 --> PID 14875 = /usr/libexec/gdm-simple-greeter
PID 14817 --> PID 14896 = pam: gdm-password
PID 1 --> PID 7119 = /usr/sbin/sshd
PID 7119 --> PID 14975 = sshd: tom [priv]
PID 14975 --> PID 14978 = sshd: tom@pts/0
PID 14978 --> PID 14979 = bash

gdm and xfce4

On a system without xfce installed, you do NOT get a menu choice from gdm allowing you to start up xfce. Once you do yum groupinstall xfce, the menu option miraculously appears.
Have any comments? Questions? Drop me a line!

Adventures in Computing / tom@mmto.org