mjhjmtu

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.

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.

BUGS

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.