Exec from root's login shell to Bash responsible for wrong env of init procs?

[Ralph Grothe]

Hello sysadmins,

I encounter some strange behaviour of a backup daemon (i.e. IBM's/Adstar's ADSM client) spawned by an init script during runlevel change (viz. reboot).
It looks as if the daemon is initializing its environment differently than on the other nodes of the same cluster.
Init scripts on all nodes are identical, and include in the "start)" regex match of the usual case block the line

export DSM_LOG=/usr/adm/adsm &&/usr/bin/nohup /usr/adsm/dsmc schedule > /dev/null &

When the ADSM client had been started through init on this particular node our backup script for the database exits on this trivial condition:

export ORACLE_SID=$1

# many lines in between

# test if SID is running
if ps -fu oracle | grep -qe "ora_dbw0_${ORACLE_SID}"; then
: # connect to SID and do backup
else
: # die
fi

When instead the ADSM client was started manually from the root shell all works fine.

Because the only difference to the other nodes (where the backup script succeeds "even" with the init spawned ADSM client) is that I gave root a more featureful shell (i.e. Bash) than the standard Bourne shell (even despite POSIX extensions).
I know that it usually is a no-no to give root another "login" shell because of the perils of possibly missing shared libs of dynamically linked shells in single user mode.
But I thought to have it done in a somewhat cautious manner.
Here's an excerpt from root's .profile:

# THIS SHOULD BE LAST EXECUTION BLOCK IN THIS FILE
# if available bail out to a better shell
if [ -t -a -x /usr/bin/bash ]; then
if [ -x ${HOME}/.bashrc ]; then
BASH_ENV=${HOME}/.bashrc
export BASH_ENV
fi
echo "Switching from login shell $SHELL to Bash for $LOGNAME"
exec /usr/bin/bash
fi

Would it help to prepend a '-' to the first arg to exec to notify a kind of login shell?

I'm convinced that all will work if I comment this last if block, but I like to have Bash for root (ok, one could issue "bash" on root's prompt at any time)

While trying to track the cause I came across this warning in the init manpage which left me a bit suspecious:

One particular scenario that often causes confusing behavior can occur
when a child csh or ksh is started by a login shell. When boot init
is asked to change to a run level that would cause the original login
shell to be killed, the shell's descendant csh or ksh process does not
receive a hangup signal since it has changed its process group
affiliation and is no longer affiliated with the process group of the
original shell. Boot init cannot kill this csh or ksh process (or any
of its children).

Could this be the cause why there are quite a few seemingly stale logins in the wtmp file?

# last root | grep still | wc -l
17

[Alexander M. Ermes]

Hi there.
You should do any Oracle jobs as user oracle
( su - oracle -c "..." ).
The user oracle should have the Korn shell as standard shell. NOT bash.
We start some jobs from the cron that way and they work. If you do it like su oracle you will only have your environment for the job instead of the environment for the user oracle.
Rgds
Alexander M. Ermes

[Santosh Nair_1]

Ralphe,

I think its a bad idea to be execing another shell from root's .profile. This would be just as bad as changing root default shell. Instead of doing it this way, how about creating another root level account, i.e. one with UID=0, and setting the default shell for that account to bash. This way, you leave the "real" root alone and you can customize your alternate root environment to fit your needs.

-Santosh

[Carlos Fernandez Riera]

1- The init process do not read root profile.

2- If you try to force exec whit bash or other sh use

#! /usr/bin/ksh # or your shell path.

3-I dont think that 'still logged in' could be caused by init process; init process do not loggin into system, init starts logins processes.

Try to reset history login files such as /var/adm/btmp, /var/adm/wtmp, and reboot to check if that message comes from init process.