I try to call /usr/bin/agetty - from bash in a terminal-emulator(both X-based and Kernel-based), then it asked me to input a username, but after input that username, it just "freeze" a little while, then dropped me back into my original bash promote.

I started to wonder, agetty is started by systemd as a service using the ttyx device and execve(/usr/bin/login) so it will give me login promote, because login is configured with pam_systemd, so a systemd session will be created. But that's not the result I get when I directly run agetty - as I mentioned above, no new session is created when I check systemctl status.

Then I thought if it was because agetty run as normal user, it might check its own EUID or something, but that just cause my bash to exit after I input the username.

Ok, I checked systemctl status again, it told me systemd run this program as /sbin/agetty -o -p -- \u --noclear tty2 linux, ok, I login as root on tty2, then run agetty -o -p -- \u --noclear - linux, I got exactly the same situation as in the first place —— I was dropped back to bash again.

I need to understand these experiment results.

I'm using ArchLinux, /usr/bin/login and /usr/bin/agetty are both from the util-linux 2.33-2 package.

  • 1
    A getty process opens the named port, prompts for a login name, calls login. If you have another process already using that port (eg your existing shell) then you may get conflicts with the terminal handling. Typically you would specify an unused port to start a new session on that port. What is it you are trying to do? Dec 30 '18 at 14:39

Apparently "recursive login" used to do something useful, but it has not been expected to work on Linux for a while now.

I recommending sticking with the more commonly used techniques, such non-recursive login, or su and sudo, because these are better understood, documented, etc for current systems.

Where possible, avoid su in favour of su -l, as this gives you a clean set of environment variables.

I do not know why you see the specific result you describe. But if you do need to understand the behaviour of "recursive login", I can think of two specific points that you need to understand, about what can go wrong with it.


The undocumented BSD -r option is not supported. This may be required by some rlogind(8) programs.

A recursive login, as used to be possible in the good old days, no longer works; for most purposes su(1) is a satisfactory substitute. Indeed, for security reasons, login does a vhangup() system call to remove any possible listening processes on the tty. This is to avoid password sniffing. If one uses the command login, then the surrounding shell gets killed by vhangup() because it's no longer the true owner of the tty.

-- man login

And if you're using systemd, it tracks login sessions, but it does not allow them to be nested. This is a deliberate choice about how systemd login sessions should interact with "audit sessions". su / sudo do not escape the current "audit session".

Currently, I can also see systemd noisily logging about this design every time I run sudo. Do not ask me why this is considered desirable...

sudo[1079]: pam_systemd(sudo:session): Cannot create session: Already running in a session

Full disclosure: the quote from man login continues:

If one uses the command login, then the surrounding shell gets killed by vhangup() because it's no longer the true owner of the tty. This can be avoided by using exec login in a top-level shell or xterm.

  • 1
    ArchLinux doesn't get this, maybe you have pam_systemd configured for sudo in /etc/pam.d. Dec 31 '18 at 14:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.