|Summary help replacing me|
|An overview of the primary configuration file for the xinit (startx) program.|
|Start X at boot|
~/.xinitrc file is a shell script read by
startx. It is mainly used to execute desktop environments, window managers and other programs when starting the X server (e.g., starting daemons and setting environment variables). The
startx programs starts the X Window System and works as first client programs on systems that cannot start X directly from
/etc/init, or in environments that use multiple window systems. The
~/.xinitrc file is a simple way to start X, typically used in conjunction with the inittab method.
One of the main functions of
~/.xinitrc is to dictate which client for the X Window System is invoked with the
/usr/bin/xinit program on a per-user basis. There exists numerous additional specifications and commands that may also be added to
~/.xinitrc as you further customize your system.
/etc/skel/ contains files and directories to provide sane defaults for newly created user accounts. (The name skel is derived from the word skeleton, because the files it contains form the basic structure for users' home directories.) The package will populate
/etc/skel with a framework
Copy the sample
/etc/skel/.xinitrc file to your home directory:
$ cp /etc/skel/.xinitrc ~/
~/.xinitrc and uncomment the line that corresponds to your DE/WM. For example, if you want to test your basic X configuration (mouse, keyboard, graphics resolution), you can simply use xterm:
#!/bin/sh # # ~/.xinitrc # # Executed by startx (run your window manager from here) # exec gnome-session # exec startkde # exec startxfce4 # exec wmaker # exec icewm # exec blackbox # exec fluxbox # exec openbox-session # ...or the Window Manager of your choice exec xterm
~/.xinitrc properly, it's time to run X. To run X as a non-root user, issue:
Your DE/WM of choice should now start up. You are now free to test your keyboard with its layout, moving your mouse around and of course enjoy the view.
If you experience trouble with automounting, try inserting
ck-launch-session between the
exec statement and the DE/WM statement. For example:
exec ck-launch-session gnome-session
ck-launch-session part ensures that the various environment variables are set correctly by starting a clean ConsoleKit session. ConsoleKit is a framework for keeping track of the various users, sessions, and seats present on a system. It provides a mechanism for software to react to changes of any of these items or of any of the metadata associated with them. It works in conjunction with D-Bus and other tools.
Following is a simple
~/.xinitrc file example, including some startup programs:
#!/bin/sh xrdb -merge ~/.Xresources # update x resources db xscreensaver -no-splash & # starts screensaver daemon xsetroot -cursor_name left_ptr & # sets the cursor icon sh ~/.fehbg & # sets the background image exec openbox-session # starts the window manager
Following example can be used as a template for executing various window managers, by uncommenting the one to be used, e.g. Openbox:
#!/bin/sh # # ~/.xinitrc # # Executed by startx (run your window manager from here) # # exec ion # exec jwm # exec wmaker # exec startkde # exec icewm # exec pekwm # exec blackbox # exec /usr/bin/ratpoison # exec gnome-session # exec startfluxbox # exec startxfce4 # exec xfce4-session exec openbox-session # exec startlxde
exec is recommended as it replaces the current process with the manager, but it's not necessary if all additional desktop/window managers are commented out as in the above example. Use the full path to the window manager or desktop environment launcher when possible. You can get the path to it by using
type - i.e.
In addition to the examples provided here, you can find another at
/etc/skel/.xinitrc provided by . To use it, simply copy it to your home directory:
$ cp /etc/skel/.xinitrc ~/
When a display manager is not used, it is important to keep in mind that the life of the X session starts and ends with
~/.xinitrc. This means that once the script quits, X quits regardless of whether you still have running programs (including your window manager). Therefore it's important that the window manager quitting and X quitting should coincide. This is easily achieved by running the window manager as the last program in the script.
Note that in the first example above, programs such as
sh are run in the background (
& suffix added). Otherwise, the script would halt and wait for each program and daemons to exit before executing
openbox-session. Also note that
openbox-session is not backgrounded. This ensures that the script will not quit until openbox does. If you run the
startx script manually, ending the script will terminate X and leave you with whatever virtual consoles
/etc/inittab has started.
If running the file from
/etc/inittab and have set the line to
respawn instead of
~/.xinitrc will be re-run. This way X can be restarted without having to restart the computer.
The following sections explains how to configure
~/.xinitrc for Multiple WMs and DEs.
On the command line
If you have a working
~/.xinitrc, but just want to try other WM/DE you can run it by issuing
xinit followed by the path to the window manager:
Note that the full path is required. Optionally, you can pass options to the X server after appending
-- - e.g.:
xinit /usr/bin/enlightenment -- -br +bs -dpi 96
The following example
~/.xinitrc shows how to start a particular window manager with an argument:
#!/bin/sh # # ~/.xinitrc # # Executed by startx (run your window manager from here) if [[ $1 == "fluxbox" ]] then exec startfluxbox elif [[ $1 == "spectrwm" ]] then exec spectrwm else echo "Choose a window manager" fi
Using this example you can start fluxbox or spectrwm with the command
xinit fluxbox or
You can also have a choice of window managers and desktop environments at startup, using just
~/.xinitrc and GRUB and no display manager. The idea is to take advantage of the fact that Arch does not make any particular use of the runlevel system. The following
~/.xinitrc tests for the current runlevel and will start Openbox and GNOME on runlevels 5 and 4 respectively:
rl=$(runlevel | grep -o [0-6]) case $rl in 4) exec gnome-session;; 5) exec openbox-session;; esac
Choosing between different runlevels is simply a matter of cloning a GRUB entry and adding the desired runlevel to the kernel arguments. Inserting the runlevel at the end of the 'kernel' line indicates that the
inittab default of runlevel 5 should be overridden and replaced with the desired runlevel, 4 in this instance:
title Arch Linux GNOME root (hd0,2) kernel /boot/vmlinuz-linux root=/dev/sda1 ro 4 initrd /boot/initramfs-linux.img
Finally, you will need to ensure that the
~/.xinitrc file is actually run at the chosen runlevel. Using the tip from Start X at boot#/etc/inittab, you can edit the
inittab to simply run
startx on the desired runlevel which will in turn use your
x:45:once:/bin/su PREFERED_USER -l -c "/bin/bash --login -c startx >/dev/null 2>&1"
Notice that "45" means that this will happen on both runlevels 4 and 5. The final differentiation between 4 and 5 will then come in
~/.xinitrc as described above. This is preferable to attempt differentiating in the
inittab file as we stick pretty close to using the various configuration files as they were intended.
Tips and tricks
PolicyKit and ConsoleKit
Various desktop environment features and applications expect PolicyKit and ConsoleKit to be active, and will produce errors if absent. A common error to notice is the inability to access shutdown or reboot prompts from desktop environment windows, and failure to mount USB devices, CD-ROMs etc. without root permissions. Most modern display managers will start PolicyKit and ConsoleKit automatically. When only using
~/.xinitrc with e.g. startx, you should execute the window manager as follows:
exec ck-launch-session gnome-session
Starting the WM first
If you need to start your window manager before other additional applications, use the following method:
#!/bin/bash openbox & wmpid=$! urxvtd -q -f -o & xscreensaver -no-splash & fbpanel & wait $wmpid
The first line runs openbox as a background process and immediately stores the process id (
$!) in the variable
wmpid. On the last line, the wait builtin is used to wait until the process specified by