UNIX for Beginners Questions & Answers

Hello and thanks in advance for any help anyone can offer to straighten me out on this subject

I'm trying to understand non-interactive & non-login shells and having a hard time conceptualize the process a non-interactive & non-login shell goes through to start up. Particularly for background processes.

The way I understand things is when a process is started.... a region of memory is created and the child process replicates a duplicate environment of the parent by being forked. What's confusing me is when is the shell environment defined for a background process? When I think about how an interactive shell is started I get a little lost.

The way I understand an interactive shell is:

Do processes that start in the background have a similar process it steps through? This is how I envision it working:
For example... An Oracle database would have the user ID of oracle and be assigned the /bin/bash shell... Would this process accurately describe what it goes through when it starts?

For some reason this seems clunky and like I'm missing something... Could someone let me know if I'm on the right path please?

Thank you very much!

What you forgot to mention is how does a user connect... and so he has a TTY( or whaterver...) defined and keyboard, StdIn and StdOut are set to those...

what do you expect a non interactive shell to use as INPUT and output?

What will the non-interactive shell do when in the user env it reads TERM=VT100 or export DISPLAY=....
etc...

Thanks for the reply!

After giving things a bit of thought I'm mostly confused with background processes. In a hypothetical situation.... an Oracle database requires the user ID named oracle with the /bin/bash associated with it to run.

What I'm trying to figure out is when does a background process, like a database or web server, start the shell and read in any environment variables... and then does it use the shell to pass commands to the API.

If you could offer any insight to this I would be grateful!

Good practices will be to never use oracle for anything else than owner of the product, you create dba users owners of the instance it will run and put the user in group dba ( otherwise how will you recognise the processes of different running instances if they all belong to oracle? ... but thats not the point here... When are the environment set? well before you initialise the instance, that means usually you would have a start/stop script that will either set all the needed env variables or source from the user's .profile if the .profile ( or .bashrc etc... ) is written properly, that means testing if the shell is interactive or not ( yes I have boxes with more than 10 instances running... )

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... From what I've read in the Bash man page a login script shouldn't run in a non-interactive shell
It specifies a script and not a process... Which makes me wonder how does a background process owned get the environment. Also, from what I've read a background process passes commands to the API... Which makes me confused as to where a shell comes into things in this sort of scenario

Once again... thanks for your replies and patience!

The "Linux" kernel handles the scheduling/multitasking and all the I/O, and it knows what an UIDs/owner is.
But it does not know what a shell is, and does not know that a UID is stored in a passwd file.
Nevertheless the kernel handle many atomic operations. Its API towards userland is in man page section 2; in Linux you can list them with:

Code:

man -k . | grep '(2)'

The userland is all the processes. The shell is a normal process. A lot userland code is stored in shared libraries, so the processes simply load the libraries and stay small. The ps -ef command also lists some kernel threads and assignes the PID 0, while the real processes in userland have PID 1 and higher.

The criteria interactive/non-interactive and login/non-login is a matter of the shell, or of the process that invokes it. You can read more of it in the man page

Code:

man sh
man bash

The invocation of a new process is done via a couple of the kernel API functions, basically fork() and exec().

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.

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.