The Inarticulate

Just before leaving work on Friday, I encountered a bizarre issue: gnome-session suddenly failed to start, and the log files provided no root cause. Today, working from home, I decided to debug it thoroughly.

The setup process was quite tedious: first, connecting to the corporate network via VPN, then logging into the corporate machine via SecureCRT, and installing x11vnc. Since running X applications remotely requires a local X Server, I booted up Ubuntu in VMware, started X, and used ssh -X to enable X11 Forwarding. However, x11vnc still refused to start because the user hadn’t logged in yet, which required configuring gdm for automatic login. I discovered that editing /etc/gdm/gdm.conf-custom directly was the easiest approach, adding the following snippet:

[daemon]
AutomaticLoginEnable=true
AutomaticLogin=username
#TimedLoginEnable=true
#TimedLoginDelay=10
#TimedLogin=username

After restarting gdm and continually monitoring with the w command, I confirmed the user was logging in automatically. The script executing was /etc/gdm/Xsession, which would immediately fail and trigger an error dialog instead of properly reaching /usr/bin/gnome-session. I opened /etc/gdm/Xsession, added the -x parameter to the #!/bin/sh shebang, and redirected the execution trace by prepending:

exec 1>/tmp/x.log 2>&1

Restarting gdm again and inspecting /tmp/x.log revealed the culprit:

++ '[' '!' -d /etc/X11/Xsession.d ']'
+++ /bin/ls -F --color /etc/X11/Xsession.d
++ for F in '$(ls $1)'
++ expr '^[[0m^[[0m20xorg-common_process-args^[[0m' : '[[:alnum:]_-]\+$'
++ for F in '$(ls $1)'
++ expr '^[[0m30xorg-common_xresources^[[0m' : '[[:alnum:]_-]\+$'
...

The moment I saw those ^[[0m control characters, everything made sense. The ls command had been aliased to /bin/ls -F --color, and the terminal color codes were breaking the script logic. It’s surprising to see such a fundamental oversight in a core system script! The initialization script reads from /etc/profile and $HOME/.profile, and if either sets this --color alias, the session launch fails. In my case, it was globally set in /etc/profile.

The fix was trivially simple: update the script to use the absolute path /bin/ls instead of relying on the environment’s ls.

Given the headache this caused, I decided to report it to the Ubuntu bug tracker. I found that others had encountered and reported it, but hadn’t pinpointed the exact root cause, so I gladly added my findings to the ticket.

• Bug #48876: gnome-session fails when “alias ls=‘ls –color’” in .profile

Update:

Shortly after reporting this, Canonical (the company behind Ubuntu) actually mailed me 5 physical Live CDs as a thank you! Back in those early days, receiving a package of physical installation CDs all the way from across the world was an incredible feeling. It perfectly captured the pure joy and tight-knit community spirit of contributing to the early open-source movement—knowing that a few hours of debugging on a weekend could positively impact thousands of users globally.