Is Shell a daemon

linuxoperating systemsshellunix

A Linux daemon is a program that is started as part of the init process. It is not associated with a terminal.

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?

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)?

Thanks in advance.

Best Answer

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.

Related Question