Few user processes talk directly to the kernel. It is an hierarchy of processes starting with PID 1 which is "init". Ultimately in ever process tree init will be at the top (or bottom depending on point of view). Some processes you can see have 1 as PPID. Others you'll see have a different PPID and in turn the PPID of that parent may have yet another and so on but ultimately you'll see a PID that has 1 as the PPID if look at the tree.
Quote:
Originally Posted by bodisha
The oracle instructions say to create a user ID named oracle, assign the /bin/bash shell to it, and create a ~/.bash_profile file set the umask to 022. From what's read in the Bash man page the ~/.bash_profile is read for login shells.
|
It is true that logins do read startup files such as /etc/profile, /etc/bashrc, $HOME/.bash_profile etc... It is NOT true that only logins CAN do this - it is just that by design logins do. You can source any of these files in a script but as I noted before you sometimes don't want to source those files because they are doing things that make sense for a logged in user but not a background process. A background process is not going to have a terminal.
Given that, it is often done that instead of sourcing the standard login files you create a completely different file that has all the environment variables you need (e.g. ORACLE_HOME, TNSADMIN) and source that file at startup. You do not have to use BASH_ENV - you can source any file you want at startup. In fact it isn't uncommon to have one file that you're sourcing in turn source other files.
For Oracle it does expect you to create and use a user to run the environment.
For example for the processes I listed yesterday we have a user called "devora". In that user's home is a .bash_profile:
Code:
# .bash_profile
# Get the aliases and functions
if [ -f ~/.bashrc ]; then
. ~/.bashrc
fi
# User specific environment and startup programs
export PATH=$PATH:$HOME/bin
PS1="[`uname -n`] \$PWD > "
. /oracle/dev/devora/11.2.0/DEV_atltst02.env
if [ -t 0 ]; then
stty erase "^H" kill "^U" intr "^C" eof "^D"
fi
alias l='ls -ltr'
alias la='ls -la'
alias ls='ls --color=none'
The very beginning of that says to look for a file in home called .bashrc and if so source it. Sourcing means to run the file and bring in any settings it generates. (. ./file = sourcing the file, but just ./file = executing the file).
If we look at that .bashrc we see it in turn is sourcing /etc/bashrc:
Quote:
# .bashrc
# Source global definitions
if [ -f /etc/bashrc ]; then
. /etc/bashrc
fi
|
/etc/bashrc might be doing settings and might also be sourcing other files in turn.
So if you start a process by running say "su - devora -c <command>" you're telling it to become the devora user with su and with the "-" flag telling it to read in the environment so that it will do the same thing it would do on login. That means (assuming the shell in /etc/passwd for devora is bash) it will load the first file above which will then source the second file then the third (and any others if specified by /etc/bashrc OR anything it sources). All of those settings that were invoked and sourced will be inherite by <command>.
However, if <command> is a script or binary it could be setting its own variables in addition to those inherited, or replacing those inherited or removing (unsetting) those inherited. Often enough <command> is a script. That script might have several variables it is setting and may itself be sourcing other environment files.
