gdm normally redirects stderr to /dev/null when it starts (before a
user has logged in), thereby disabling potentially important messages
from libraries. If a library used by the daemon or the greeter fails
critically for some reason, it almost always prints a message to
stderr. Those messages can be crucial to be able to figure out what
went wrong, and it's therefore important that they are logged
somewhere where the user can see them.

I stumbled upon this after upgrading some font related packages in my
Debian installation. The effect after that was that gdm failed to
start the X server. No error was logged anywhere, no core, no nothing
- gdm simply bailed out when it tried to display the greeter
(gdmgreeter or gdmlogin made no difference).

It took several hours of determined debugging to figure out that it
was the pango library that couldn't load neither the requested font
nor the fallback font. That caused it to call exit(3) (should be
abort(3) - I've filed a report about that too) which made gdmgreeter
very short lived. The pango library did however log several messages
about the problem to stderr before that, which I didn't get to see.

The really nice thing to do here is to install a pipe on stderr (and
preferably also stdout) and send the output on to syslog. Failing that
it should go to a log somewhere, somewhat like a system-wide analogy
to $HOME/.xsession-errors.