I am reading APUE and it keeps refering to the login program, but I still don't know what it is doing in my operating system (Ubuntu).


Normally, the real user ID is set by the login(1) program when we log in and never changes. Because login is a superuser process, it sets all three user IDs when it calls setuid

ps aux | grep login:

root       840  0.0  0.0  70732  6120 ?        Ss   15:13   0:00 /lib/systemd/systemd-logind
root      1120  0.0  0.0 419680  9468 ?        Sl   15:13   0:00 gdm-session-worker [pam/gdm-autologin]
tianhe    1151  0.0  0.1 445184 20540 ?        SLl  15:13   0:05 /usr/bin/gnome-keyring-daemon --daemonize --login
tianhe   10838  0.0  0.0  21536  1060 pts/0    S+   21:50   0:00 grep --color=auto login

So in short, what functionality does this login program provide for the OS?

Under what circumstances it is used or run?

Btw, how is login compared to ssh?

  • I Googled it before asking but did not find any useful posts explaining the use of it :(.
    – Rick
    Mar 16, 2019 at 17:12

2 Answers 2


It isn't a command for you to run interactively.

The login command is not normally entered on the command line.
login manual. IBM AIX 7.2

It used to be. Back in the 1980s, this would work, and C-shell users even had a convenience login built-in command which would exec the external login program, overlaying the shell process with that program, which was set-UID to the superuser.

But operating systems do not work nowadays like BSD of the 1980s. A login session (which is the type of session being discussed there, by the way) goes through too many one-way trapdoors (user security contexts, control groups, changed-UID "taint" markers, AIX setsenv, and so forth) for it to be feasible to correctly start a fresh login session for an arbitrary user from a process that is already in a user login session.

And in any case, because of the advent of PAM in the 1990s, the shell process that would be overlaid with the new login program is no longer the topmost process in the tree as it was in the 1980s. It's now a child of a supervisory process, that is doing PAM session setup and teardown.

This is why "dæmonization" is a fallacy and this is why running login from within an existing login session is not really sensible.

It is a system program.

login is invoked by terminal login services, usually directly, after the service or the service management infrastructure has set up some environment variables, opened the terminal device and initialized/pushed the line discipline, set it as the controlling terminal, and initialized the terminal with some control sequences.

  • On AT&T Unix System 5 Release 4 back in 1987, these would be services managed by ttymon, part of the Service Access Facility. You can still see these today on OpenSolaris and its derivatives such as Illumos and Schillix.
  • On systemd Linux operating systems these are the autovt@something services (usually aliases for getty@something services). This is the notable odd-one-out of the System 5 side of the universe, still using a getty program to invoke login when almost no-one else does any more.
  • On operating systems using the nosh toolset for service management, these are the ttylogin@something services.
  • In the BSD side of the universe, if not using nosh service management, these are services spawned by process #1 according to the /etc/ttys table.

If you logged in on a virtual terminal, or a real terminal, it was login that prompted you for your password, and possibly for your user name as well, and then proceeded to invoke your interactive login shell.

login is not used by SSH login. Nor is it used by GUI login. Both of these operate differently, using other programs. login expects to be talking to a terminal, with a Textual User Interface.

It is used by the old Berkeley rlogin system, but you should not be employing that nowadays. Further discussion of the so-called Berkeley "r-" commands is way beyond the scope of this answer. So I'll just say that this is something else that isn't done any more the way that it was in the 1980s.

Further reading


You probably login to a windowing session, in this case a display manager xdm, gdm, kdm … will log you in. However there are other ways to login. For example over a network we can use (as you have pointed out) ssh. If we login locally, but not into a windowing system, then we need a different login program. This is where login comes in.

Try pressing ctrlaltf1, login then have a look at what processes are running. What logged you in.

  • Thank you. Combining with the answer by @JdBP, I seems to understand. However, ctrl + alt + f1 does not prompt anything ( I am using Ubuntu) :(
    – Rick
    Mar 18, 2019 at 15:39
  • That's because the ctrl + alt + f# switches between vt#, and your gdm login manager is likely running on vt1, which is reached from ctrl + alt + f1. Try ctrl + alt + F2 through F8 (sheesh, why doesn't <kbd>x</kbd> work in comments?)
    – Rich
    Mar 18, 2019 at 16:35
  • @Rich Are you kidding me? My system crashed after I pressed ctrl + alt + F2 :(
    – Rick
    Mar 19, 2019 at 1:05
  • @rick you may have some hardware/driver problems (What graphic hardware are you using?). Mar 19, 2019 at 8:40
  • Hmmm, I am using product: GP106 [GeForce GTX 1060 3GB]...
    – Rick
    Mar 19, 2019 at 9:47

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .