xinitrc

From ParabolaWiki
Jump to: navigation, search
Summary
An overview of the primary configuration file for the xinit (startx) program.
Related
Display Manager
Start X at boot
Xorg
xprofile

The ~/.xinitrc file is a shell script read by xinit and 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 xinit and 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/startx and/or /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.

1 Getting started

/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 xorg-xinit package will populate /etc/skel with a framework .xinitrc file.

Note: ~/.xinitrc is a so-called 'dot' (.) file. Files in a *nix file system which are preceded with a dot (.) are 'hidden' and will not show up with a regular ls command, usually for the sake of keeping directories tidy. Dot files may be seen by running ls -a. The 'rc' denotes Run Commands and simply indicates that it is a configuration file. Since it controls how a program runs, it is (although historically incorrect) also said to stand for "Run Control".

Copy the sample /etc/skel/.xinitrc file to your home directory:

$ cp /etc/skel/.xinitrc ~/

Now, edit ~/.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
Note: It is important that only one exec line is uncommented, or else only the first uncommented line will be run.

After editing ~/.xinitrc properly, it's time to run X. To run X as a non-root user, issue:

$ startx

or

$ xinit

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
Note: This requires that you have the consolekit package installed.

The 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.

2 File examples

Following is a simple ~/.xinitrc file example, including some startup programs:

~/.xinitrc
#!/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:

~/.xinitrc
#!/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

Prepending 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. type startkde.

3 File configuration

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 cairo-compmgr, xscreensaver, xsetroot and 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 once, ~/.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.

3.1 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:

xinit /full/path/to/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:

~/.xinitrc
#!/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 xinit spectrwm.

3.2 At startup

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 ~/.xinitrc script:

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.

4 Tips and tricks

4.1 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
Note: Beware that polkit and consolekit packages must be present in your installation.
Note: If you derived your ~/.xinitrc from /etc/skel/.xinitrc, it will have a snippet at the top that sources the scripts in /etc/X11/xinit/xinitrc.d/, including /etc/X11/xinit/xinitrc.d/30-bus, which thus starts dbus before ConsoleKit: this causes bug Issue#25031, since it is necessary to launch dbus after ConsoleKit, or you will have authorization problems when mounting drives.

As a temporary workaround you can edit the snippet in ~/.xinitrc as follows:

if [ -d /etc/X11/xinit/xinitrc.d ]; then
  for f in /etc/X11/xinit/xinitrc.d/*; do
    # Do not launch dbus before ConsoleKit (FS#25031)
    #[ -x "$f" ] && . "$f"
    [ "$f" -ne "/etc/X11/xinit/xinitrc.d/30-dbus" ] && [ -x "$f" ] && . "$f"
  done
  unset f
fi
This will let you properly start dbus after ConsoleKit, follow the article of your Window Manager or Desktop Environment for detailed instructions.

4.2 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 wmpid terminates.

5 See also

6 Acknowledgement

This wiki article is based on ArchWiki. We may have removed non-FSDG bits from it.