Category Archives: Linux/Unix

Xorg config silently got better

Since my first XFree86 (v3), I got used to the annoying /etc/X11/XF86Config file (now /etc/X11/xorg.conf), and I didn't notice that editing this file already belongs to the dinosaurs era. Quite silently, new features emerged and gave better ways to configure X, in particular screen resolutions. I'll sum up what I've found out today, in a bullet fasion:

  • The modern xorg actually no longer needs the xorg.conf file. xorg simply knows what to do automagically :). xorg.conf file can be used though, for overriding the defaults. Still, only the overrided stuff can be written, and the file is still small and readable.
  • xrandr --mode changes the resolution on the fly (not permanently though), from a list of given resolution. Thank you, HP, this time you did something good 🙂
    • xrandr --newmode , xrandr --addmode: add new resolutions to that list.
    • Still, X may have an upper resolution limit which it won't let you pass. It can be increased by adding a "Virtual" line to xorg.conf (Screen section -> Display subsection). i.e. "Virtual 1280 768" would set a maximum resolution of 1280x768.
  • cvt is a cool tool for generating Mode Lines, simply amazing! Needed for xrandr --newmode command.
  • Setting a new resolution permanently: this Ubuntu howto suggests to simply add the correct xrandr commands (i.e. xrandr --mode 1280x768) to the ~/.xprofile script. These commands would run right after each X login for that specific user. (There's probably a system-wide equivalent)
    • GNOME (and probably KDE as well) has its own resolution settings, which seems to override the xrandr change. So if using GNOME, configuration should be simply changed from within the GNOME tools..

Good stuff. It's always nice to see how things got better in few years. Still, in my opinion xorg has many problems (and slow development cycle), and might be the weakest link on Linux desktops. Goodbye!

/etc/mtab weirdness

There are many ways to fetch the list of currently-mounted-devices: read the files /etc/mtab, /proc/mounts, or exec /bin/mount, /bin/df.

I've been arguing with a colleague (Yaniv), that relying on /etc/mtab is no much worse than relying on /proc/mounts. But after we inspected it on Linux & Solaris (/etc/mnttab), I figured out that I was pretty wrong, and learned some new surprising facts:

On Linux:

  • /proc/mounts is a read-only, kernel-generated file.
  • /etc/mtab (Linux) is a regular file. It's kept up-to-date because the mount/umount commands modify it. It can be modified by a root user, moved and even deleted!
  • df command is using /etc/mtab, thus after rm'ing /etc/mtab, df would stop functioning.
  • mount command doesn't care about /etc/mtab, probably uses /proc/mounts or some internal kernel structure.

On Solaris (prepare for some weird stuff now):

  • Solaris has got /etc/mnttab, but no /proc/mounts equivalent.
  • /etc/mnttab is a mounted filesystem, of the mntfs type. So it's somewhat similar to /proc/mounts on Linux. It cannot be modified.
  • /etc/mnttab is actually a directory! (a mount point has to be a directory..)
  • /etc/mnttab can be unmounted, renamed, rmdir'd (when unmounted) and mounted anywhere else.
  • both df and mount rely on /etc/mnttab, thus not functioning when it's absent


  • /etc/mnttab, which is a regular file, is similar to /etc/mtab on Linux.

And on another, non-related subject: looks like Debian Lenny has got only 80 bugs to go (as of 19/01/09)! Go Lenny!

Init script dependency

"Behind my back", a new feature was added to LSB specification and to Debian Lenny accordingly: Init scripts dependency.

The new LSB defines new fields for init script headers: Required, Should (like Required but only if installed) and Provides. This means that the init system should take care of ordering the init scripts according to their dependencies (i.e. "NFS" service requires "portmap" service which requires network and thus order should be Network -> Portmap -> NFS). This eliminates the need to give funny "K01/S99"-style numbers manually to each service.

Cool. But is it enough? The init system is several decades old. Maybe we need something revolutionary such as Upstart or Solaris SMF. Features like starting/stopping independent services in parallel, service monitoring (watchdog/keepalive), or other crazy ideas that Upstart & SMF implement.

Ubuntu's Upstart was adopted also by Fedora 9; this means that RHEL6 might use Upstart as well. In that case, the revolution is over.. Debian, SuSE (and Windows maybe? 🙂 ) would probably follow.