Quote:
Originally Posted by
bodisha
Thanks for the reply again... You sort of touched on the part of where I'm getting confused at. My understanding of a background process like a user ID for an Oracle database is it would be a non-interactive and non-login shell...
The shell is not actually in charge, it just helps arrange things. The shell isn't necessarily involved at all in creating the Oracle process, or creating any other process for that matter.
The one and only difference between "interactive" and "noninteractive" processes, as far as the kernel is concerned, is whether your process has a controlling terminal. The kernel knows what your terminal is even if your process doesn't - you can open it via /dev/tty. The kernel doesn't really
care whether you have a terminal.
In the old days terminals were really terminals - physical devices attached to serial ports. /bin/login did the job of holding those ports open and reading username/passwords from them. Each port would have one /bin/login process running for it. These days, things like ssh have mostly taken over the job of sitting around and waiting for user input, terminals have become imaginary devices which get created and destroyed at need.
The
login program creates your shell. It owns the terminal, and opens it, duplicating it onto file descriptors 0, 1, and 2 for you - standard input, standard output, and standard error. Then
login runs your shell and lets it take over from there.
Quote:
It specifies a script and not a process... Which makes me wonder how does a background process owned get the environment.
When a process is created, it receives a copy of the environment of its parent. So it comes down to where the parent got
its environment.