Automated Logins Revisited

By Adrian J. Chung

As more users adopt GNU/Linux for use on their desktop PCs, machines with only one user are becoming increasingly common. Many new users have little use for the multi-user logins that Linux supports. A very common request among new desktop users is to configure their Linux systems to automatically boot up a graphical desktop environment (i.e. KDE or GNOME), for a single unprivileged user, without prompting for a login ID or password.

This question is asked so frequently I am surprised that a HOWTO has not been written up for it. (Well, none that I can find.) This article is in no way comprehensive enough to fulfill such a role, but hopefully it will point users in the right direction.

Prepackaged solutions

Solutions to automated logins have been proposed before and one answer appears in an earlier issue of Linux Gazette (http://linuxgazette.net/issue27/kodis.html) The particular solution requires patching the /sbin/mingetty program that is launched by init on bootup. (See http://users.jagunet.com/~kodis/autologin/autologin.html for the patch and how to apply it.) Although automatic logins on virtual consoles are facilitated, this by itself will not initiate a graphical desktop. Read below for tips on how to set this up.

Alternatively one can install the autologin package (http://www.linux-easy.com/development/autologin/) This can handle the launching of graphical desktops on bootup also. Not many GNU/Linux distributions include this as standard.

Automatic login is a feature provided by recent versions of kdm (a KDE-style replacement for xdm -- the X11 login manager). Edit the /etc/kde2/kdmrc so that the following lines are uncommented:

AutoLoginEnable=true
AutoLoginUser=fred

This configures kdm to automatically login fred on startup, initiating fred's chosen graphical desktop environment without any user interaction. Mandrake provides a GUI component to enable this kdm feature, thus avoiding any messy text editing.

But maybe one does not want nor need to install kdm. (Perhaps there is not enough disk space, or kdm is too heavy weight for an older PC.) Fortunately there are ways to automatically login a user on one of the virtual consoles immediately after booting up, without resorting to patches or additional downloads. The process can be somewhat more involved, but it will work on a pretty minimal GNU/Linux box -- no need to have GNOME, KDE, or QT-heavy kdm. Even without X an automated login to a command prompt (or any other interactive console application) on bootup can be quite handy.

The nuts-n-bolts method

Using your favourite text editor create a file named autologinfred.c and type in this short C program:

int main() {
   execlp( "login", "login", "-f", "fred", 0);
}

The execlp system call invokes the command "login -f fred" and replaces the current processing context with this invocation. The man page for login describes the action of the -f argument. Compile this tiny C program using the GNU C-compiler:

$ gcc -o autologinfred autologinfred.c

Gain root privileges (using su) and copy the executable to a public directory: # cp autologinfred /usr/local/sbin/ Now take a look at /etc/inittab. This is the configuration file is used by init, the very first process started when Linux initialises. You should observe lines similar to the following: 1:2345:respawn:/sbin/mingetty tty1 2:2345:respawn:/sbin/mingetty tty2 3:2345:respawn:/sbin/mingetty tty3 The exact contents of /etc/inittab differ from distribution to distribution. On Debian systems one sees: 1:2345:respawn:/sbin/getty 38400 tty1 2:23:respawn:/sbin/getty 38400 tty2 3:23:respawn:/sbin/getty 38400 tty3 Edit the line beginning with "1:2345" so that it reads as follows: 1:2345:respawn:/sbin/getty -n -l /usr/local/sbin/autologinfred 38400 tty1 The above will cause the user fred to be logged in automatically on the first virtual console. On some GNU/Linux distributions (like RedHat) /sbin/agetty must be used instead. The -l <alternative login> argument to getty substitutes the default /sbin/login program with the one we compiled earlier. The -n tells getty to not prompt for a user ID. Initiating the desktop on login If we reboot, the init process will automatically login the user fred on the first virtual console and a command shell will by started. User fred must still type in the startx command to initiate the graphical desktop. Can we automate this too? If fred's login shell is /bin/bash, the first commands to be executed will always be listed in the file, ~fred/.bash_profile. We can add the startx command here but this causes problems, since the .bash_profile will be used in other situations such as when one is logging into a second virtual console or when opening an xterm. Instead we append the following lines: if [ -z "$DISPLAY" ] && [ $(tty) == /dev/tty1 ]; then startx fi Any new login shell started on the first virtual console will automatically initiate a graphical desktop. The surrounding if statement ensures that login shells launched from the desktop, or initiated in virtual consoles other than the first one, do not immediately start up a new GUI desktop. Users of /bin/sh should append the above to ~fred/.profile, and tcsh users need to convert the above to the equivalent csh script. If there is already a GUI desktop running (via xdm, gdm or kdm, etc) then invoke startx -- :1 instead. This creates a second GUI desktop. If one need only have one desktop active, it would be better to disable any existing Xserver instance by reducing the run level (RedHat) or unlinking the /etc/rc?.d/S99?dm start up configuration files (Debian). Variations Now whenever the machine boots, user fred is automatically logged into the first virtual console, a bash login shell is initiated, his ~/.bash_profile is sourced, and startx is invoked -- all without any user interaction or prompting for passwords. Neat, huh? We can go further by making use of the ~/.xinitrc file to initiate particular desktop applications. (man startx for details.) Place your favourite game here and a Linux box can be used like one of those arcade machines, minus the decorative case. Launch an Ogg Vorbis player with visualisations and you can have a dedicated music machine. Unprompted logins can also be useful in a non-graphical context. One could arrange to login a special user who has /usr/bin/top as her shell. Now one virtual console will be devoted to an interactive listing of active processes. The possibilities are limitless. Conclusion GNU/Linux, the multi-user operating system, is steadily becoming more popular in single user settings. In these situations one often can dispense with the user login protocols. This article illustrates that its roots in the UNIX world do not detract from using Linux in these dedicated areas. With simple changes in configuration, and a small touch of programming, one can automate the login process on most GNU/Linux distributions and still preserve a significant measure of flexibility. Adrian J Chung When not teaching undergraduate computing at the University of the West Indies, Trinidad, Adrian is writing system level scripts to manage a network of Linux boxes, and conducts experiments with interfacing various scripting environments with home-brew computer graphics renderers and data visualization libraries. Copyright © 2001, Adrian J. Chung. Copying license http://www.linuxgazette.net/copying.html Published in Issue 72 of Linux Gazette, November 2001