Problems with nohup

[Brian Atkins]

When attempting to nohup a script, the script apepars to start, but hangs. After entering the command, nohup reports back with the PID, but doesn't return to a command line. If I touch , I receive a second messsage that the script has stopped.

# nohup /root/bin/ett_load.ksh &
[1] 2496
# Sending output to nohup.out

(hangs so I touch )

[1] + Stopped (tty output) nohup /root/bin/ett_load.ksh &

The man pages state that nohup will fail if the user does not have sufficient permission to write to the current directory or to their home directory. However, this is not the case, especially since the script requires to run as root.

I am certain that the problem is not with the script itself as I have tried it without nohup and it functions as advertised.

The only item that I think might be affecting it is that the script su's to several users to perform different functions.

[James R. Ferguson]

Hi Brian:

The 'su' within your script may be causing the problem. If the script is running as root, then no password is necessary to do the 'su'. If you are not running as root, and issue an 'su' then the process is attempting to read from stdin. Since redirection to 'su' isn't allowed, the script will hang.

...JRF...

[Brian Atkins]

James,

When the script is being executed I am logged in as root and the script is being run as root. The su's in question are to oracle and another user.

Brian

[Robin Wakefield]

What happens if you redirect stdout and stderr, even though nohup should handle it:

nohup {script} >/tmp/stdout 2>/tmp/stderr &

Robin.

[A. Clay Stephenson]

Hi Brian,

One other thing that could cause this is if somewhere in your script (and especially if your are executing .profile's) there may be a stty tostop which will block when background jobs try to produce output.

Clay

[Brian Atkins]

I tried that one, too, thinking that there might be some sort of contengency with permissions or another nohup, so I did:

# nohup /root/bin/ett_load.ksh 1>/tmp/output 2>/tmp/errors &

I did this hoping at least I might get something that would ive me some clue as to what was wrong. No dice.

By the way, system logs don't report anything unusual either.

[Laurent Paumier]

Try redirecting stdin from /dev/null. If there are commands playing with the terminal (such as stty), that might help.

[Brian Atkins]

If I understood you correctly, I did the following:

# nohup /root/bin/ett_load.ksh < /dev/null &

But, unfortunately got the same error...

[Brian Atkins]

Clay,

I checked stty setting in the .profile for the 2 users referenced in the script. What I came up with was:

stty erase "^H" kill "^U" intr "^C" eof "^D"
stty hupcl ixon ixoff

I'm not sure exactly what the second line does, but I'm pretty sure that the firstline simply gives the user the frequently used keyboard functions (i.e., backspace key, esc key). I did try commenting them out and re-running the script. No dice.

Nohup 10
SysAdm 0

[James R. Ferguson]

Hi Brian:

This is interesting. Here's a simple script that executes fine in the foreground but hangs for SIGTTOU (background process attempting write):

#!/usr/bin/sh
su - anyuser -c "echo `date`"
#.end.

Call the script "my.sh" and:

./my.sh #...works as expected...
./my.sh > /dev/null 2>&1 #...works...
./my.sh > /dev/null 2>&1 & #...hangs...

Therefore...?

...JRF...

[Brian Atkins]

James,

So what you're tring to impress upon me is the fact that:

1) The problem is not with nohup, but with the process running in the background.
2) The background process is attempting to write to the terminal, but can't and therefore hangs.

So, somewhere I need to redirect how it is writing or where it is writing to...

[Tracey]

Does anything get created in the output file? Try putting: set -x as the first line of the script. This will echo to the output file each line in the main script as it executes. That way at least you might be able to find out which line it is failing on.

[Brian Atkins]

Tracy,

I tried the set -x and got the same output in the nohup.out file. Nothing.

I don't think that the script is the problem. It really would appear to be something more like the ability of nohup (or &) to write output...

[James R. Ferguson · Accepted solution]

Hi Brian:

OK. You must be doing 'su - user'. Do a simple 'su user' and then all should be OK. Clay had it nailed. The script I posted was an effort to dissect things down to a simple test case. The SIGTTOU is the tell-all.

The 'su - user' causes "user"'s profile to be read and output. Usually this is done to get environmental variables. Instead, put the variables you need in your script and do a simple "su".

Regards!

...JRF...

[A. Clay Stephenson]

Hi Brian,

James' test made it possible to nail this.
What is going on is then the stty's and the tset's in the standard .profile are blocking when in background.

I was able to add this block of code around the stty's ands tset's and that fixed the problem.

if [ -t 0 -a -t 1 -a -t 2 ]
then
do tset and stty commands
fi

This tests if stdin,stdout, and stderr is a terminal. If so, do the stty/tset stuff otherwise bypass the stty/tset stuff.

If you will modify the .profiles of each user you su - to, I think you will be fixed.

Regards and an interesting problem, Clay

[A. Clay Stephenson]

Hi again Brian,

If you have any tabs commands in your .profile then the same rules apply.

Regards, Clay

[Deshpande Prashant]

HI
Can you try redirecting output in script to log file before you start your actual commands.

exec >LOGFILE 2>&1
...

Thanks.
Prashant Deshpande.

[Laurent Paumier]

If it's just the commands in user's .profile that hang, you could run the command in the foreground and, after a few seconds, ^Z and bg... Not a clean solution, but maybe a workaround the problem.

[Brian Atkins]

Man, this is a lot tougher than I originally thought. Alas, no joy. Clay, Laurent, and Prashant, I still cannot get it to work correctly. I have attempted all three of your suggestions, but still get the same results. Here is an excerpt from one of the .profiles, after the mod Clay suggested, that are referenced by the script:

INTER=$(set -o |grep interactive | awk '{print $2}')
if [ "$INTER" = "on" ]
then
# Set up the terminal:
if [ "$TERM" = "" ]
then
eval ` tset -s -Q -m ':?hp' `
else
eval ` tset -s -Q `
fi

if [ -t 0 -a -t 1 -a -t 2 ]
then
stty erase "^H" kill "^U" intr "^C" eof "^D"
stty hupcl ixon ixoff
tabs
fi
fi

Hope I did it correctly.

[A. Clay Stephenson]

Hi Brian,

Put the if [ -t 0 ... ]
around the tset code as well. It too will block.

Also, do a ps while you are blocked and you should see the process in question.

I would first try James's little script as an su - username -c command to see if you get the .profiles fixed before moving on to more your obviously more complicated version.

This is exactly why it is better to set up Oracle or other environments in a location like /usr/local/bin/oraenv.sh and then include them
in your .profiles via . /usr/local/bin/oraenv.sh.

You could then simply do an su username -c somescript and somescript also includes /usr/local/bin/oraenv.sh.

I think you can get your existing profiles to work,it's just more difficult this way.

Clay

[Brian Atkins]

OK! James and Clay get the big cookie on this one. I missed James' post on the last reply. I did exactly as you specified, taking out the '-'s and placing env variables in the script. It worked like a charm.

I will take some time later to do as Clay suggested and make a separate file for env variables.

James, I really appreciate the assist by leading me to the answer rather than just dropping it in my lap. At least I think that is what you intended to do. In any event, thanks to everyone for their suggestions.

Now I can go on vacation without this thing nagging at me!

[James R. Ferguson]

Hi Brian:

In lieu of changing your .profiles, try including the paths and variables you need in the scripts you need to run rather than sourcing their $HOME/.profiles with the 'su - username -c scriptname' syntax. That is, use the form 'su username -c scriptname'.

Regards!

...JRF...

[James R. Ferguson]

Hi Brian:

Glad we got to the bottom. Like Clay said, this was an interesting one. Thanks!

I developed the test script to dissect things to an elemental level for the purposes of analysis. I wanted a quick resolution and felt we were so close to "smelling the roses" that posting it would give everyone an opportunity to quickly solve it. It seems so obvious in retrospect... ;-)

Regards!

...JRF...

[Bill Thorsteinson]

You can run into similar problems with at, cron, and
batch. I use a standard wrapper around anything
that depends on having a termimal using the 'stty'
command to determine if I am running at a terminal.
This examples lets the user know where and when
they logged in.

if /usr/bin/tty -s ; then
echo
echo "$LOGNAME on `uname -n` at `date`"
echo
fi

and this one prevents oracle from prompting for
SID if there is nowhere to prompt (comments wrapped).

if /usr/bin/tty -s; then
# Are we at a terminal or batch?
ORAENV_ASK=${ORAENV_ASK:-NO}
# Default no prompt
else
ORAENV_ASK=NO
# Force no prompt
fi

I don't have a ready example for setting terminal
characteristics.