Is Shell a daemon?

Solution 1:

So almost all Linux systems which boot to run level 3 will wait for user to login at the terminal. So is that terminal process is a daemon?

The traditional way that the terminal logon process worked under Linux (and other Unix systems) before systemd is the following:

• init is configured to keep one or more getty processes running - meaning when the getty process exits, init will start it again.

• Each getty opens a device that needs to have a login prompt. This can be the virtual ttys on the text-mode screen /dev/tty0 etc., or actual serial ports /dev/ttyS0 that you can still connect a classical real terminal like a VT220 if you still wanted to, or have modems connected to for dial-in capability.

• getty outputs the /etc/issue and [hostname] login: prompt on the device it's told to open (usually specified in the inittab line) and waits for a username and password.

• If it's correct, it will open the shell of the account with an exec() style-system call.

• What exec does is replace the current process with a new executable. Since the actual PID didn't change, init isn't triggered to restart anything yet. Since the shell is running and has replaced getty, another login can't happen on that terminal.

• When the user is done and closes the shell, init gets a signal. init then launches a new getty which asks for a login prompt again.

In this situation, getty is not a daemon - it's a non-background program waiting for input on a terminal. You might not be looking at the terminal, but it's still there in the foreground waiting for someone to input a username and password. And the shell is definitely not a daemon - it simply gets exec'ed over the getty and is a normal foreground program just like the getty it replaced.

Now - most all Linux systems run sshd which is a daemon, and it works completely differently. sshd handles the SSH protocol setup and and handles the login prompt over that SSH connection by itself - no getty's are involved with ssh. However when ssh receives a valid username/password it uses a different system call spawn() which creates a new child process. The shell is still not a daemon in this case.

For graphical logins, the desktop manager handles logins; gdm3 for example. getty's are not involved since setting up a GUI session is more complex than just exec'ing a shell.

systemd-logind - which is a daemon - doesn't really change things very much for terminal login, though. It basically takes the place of init for spawning getty's on terminals, but the getty processes are still handling the logins in the same way--and when the exec'ed shell exits, systemd-logind is then triggered to restart a new getty.

Solution 2:

The logon process is a deamon spawned by init.
It displays the login prompt on the various IO channels (tty, serial, vty, etc) and wait for a login.
After the login it checks which shell (or other program, it doesn't have to be a shell) the just logged in user has set in as its default shell and will launch that program, given it the IO-channel as the standard input/output streams.

Same applies for network logins: In that case it is the network service (ssh or telnet in most cases) that creates a "virtual terminal, aka VTY) on which the login process then handles the rest of the login process and the launch of the shell program.

In case of GUI's the GUI itself simply starts the terminal application which in turn starts the shell. (In most cases terminal/shell launched from a GUI don't go through a login as the user is already logged in to the GUI.)

So the "shell" itself isn't a deamon process, but it is often launched by one.

Solution 3:

Shells and terminals are two very different components. The terminal is what handles keypresses and draws stuff on screen, the shell is what understands the commands that are being typed.

The interactive shell is never a daemon by definition – because it is interactive. It's attached to the terminal that you're typing into.

So almost all Linux systems which boot to run level 3 will wait for user to login at the terminal. So is that terminal process is a daemon?

This built-in terminal doesn't actually have its own process at all – the Linux virtual console runs as part of the kernel. (That is, text rendering, keyboard input, etc. are handled on the kernel side.)

(The login prompt doesn't come from the terminal itself, however; it comes from the getty service, which is started as a system service through inittab or systemd, but is attached to the terminal as its "controlling tty", so it's a bit on the fence regarding being a daemon.)

Also, if systems are booted to run level 5 (with GUI), I am tempted to think that in this case, the shell is not a daemon. Basically, the user starts the terminal process. If that is the case, is the terminal associated with self (means the same terminal)?

No. A graphical terminal emulator only holds the "master" end of the pty (pseudo-terminal) device, but doesn't use the "business" end, and does not have it assigned as its own "controlling terminal".