How to properly use nohup?

[Jorge Fabregas]

Hello all,

I'm trying to leave an oracle import running after-hours. My import script (import.sh) contains:

. /home/oracle/portal-env.sh
imp userid="'sys/our_password@portaldb as sysdba'" file=/oracle/export/portal.dmp gra
nts=y log=portal-imp.log full=y


I run the script as:

nohup /home/oracle/import.sh &


But as soon as I try to exit the shell...I get the message: "The are running jobs". I quit..and then log back in and I can see the import stopped. What is the proper way to use the nohup command?

Thanks,
Jorge

[Steven E. Protter]

You use and the behavior of nohup is normal.

You should note that a file called nohup.out is created with the nohup command. Obviously runing the command twice in the same directory can result in some interesting results.

You can actually omit the nohup command and still background jobs.

/home/oracle/import.sh &

Then hit enter

jobs

You will see those running jobs. If you terminate your terminal session, say with the X if its running on Microsoft Windows, the job will continue to run in the background.

SEP

[Con O'Kelly]

Hi Jorge

Your use of the nohup command is correct.

Type "exit" at shell prompt & then exit again after the message about running jobs.
Your shell script should still keep running.

If not check there is not a problem with the script ie run it without nohup & see it continues running.

Cheers
Con

[Jorge Fabregas]

Hello all,

Thanks for your replies. I know it's weird. The thing is that the import stops. If I run it manually it works fine. If I exit after running it with nohup (and putting it in the background) ...the only way to make sure if it's working (with nohup) is to logout..then log back in and check if it's there.

If I do (after login back) a ps -ef | grep imp...the import is there in memory but it is not working. I can notice this because I look at the nohup.out and the import log.

Maybe the first line of the script (the one that sources the environment script) is causing some side effect. I'll check again. If you have any more ideas please let me know.

Thanks,
JOrge

[Mark Grant]

Any chance you could post the complete import.sh script. Everything looks OK otherwise.

[Stanimir]

Hi!
I thing your syntaksis is right.
So I had such problem /with un-normal
behavior of nohup a year ago with hp-ux 10.20/.
So, as far as remember the problem was
solved after patch-upgrade.
So please try to run this on another mashine
/with different level os or patches/.
You could compare behavior and take
the solution.

Regards,Stan

[Raynald Boucher]

Looks like more than one thing may be wrong...

Submit your job with "at now" instead of nohup. If results are identical, it's not a problem with "nohup".

I suspect it's an "import" problem.

Is your userid password correct?
Your import file has proper permissions etc?
You are doing import FULL. Does your target database layout match the source database?

[jbjbjb]

have you tried putting the nohup in your script like
...
nohup imp userid="'sys/our_password@portaldb as sysdba'" file=/oracle/export/portal.dmp gra
nts=y log=portal-imp.log full=y
...

then run your script like
/home/oracle/import.sh &

when you log out and back in you should then you should see your script with a ppid of 1 and not your old terminal ppid.

john

[Ralph Grothe]

Jorge,

as others already confirmed your usage of nohup should be ok.
Since I'm not a dba I don't do db imports.
Thus, I don't know the behavior of the Oracle imp command either.
Could it be that somehow the command (or your script) is expecting any input?
Then you should consider redirecting stdin as well.
Maybe if no such input is required an explicit closing of stdin or some strange looking redirection like "0
SEP,

though it doesn't suit to object a pharao, I don't believe that the closing of the terminal where you simply backgrounded a job by appending an ampersand without prepending the nohup command won't kill all such backgrounded jobs as well.
Afaik, when you exit the shell (i.e. the session leader) it will send all backgrounded jobs a SIGHUP which should terminate them in order not to leave orphans behind.

[Steve Lewis · Accepted solution]

The whole point of nohup is to prevent it from killing all your tasks when you disconnect.

Maybe its blocked on writing to standard error. Have you tried adding a 2>&1 to the end? For our exports we have to use

nohup dbexport dbname > txtfile 2>&1 &

which works fine and carries on running when I log out, which I do by typing exit twice.

[John Payne_2]

Jorge,

We had problems identical to yours earlier this year and we opened an issue with HP about it. I was even able to duplicate the issue with sar. (This was on HPUX 11.0, by the way.) The issue got escalated back to the lab, and they said they would have to do a defect fix for nohup. We haven't seen it yet.

I found that if you invoked another shell, then ran the nohup script, then exited your child shell, the nohup would continue to run properly.

sh
nohup sar -v 5 5 &
exit

This would always make nohup work properly. We modified the script we were having trouble with, and haven't really thought about it for months. Is it possible for you to do something like that?

Hope it helps

John

[Jorge Fabregas]

Hello everyone,

Thanks for your help.

Steve! THANKS! That was it! Redirecting stderr!!!

It seems that nohup will only redirect stdout (to nohup.out) but it doesn't redirect stderr.

I ran the script as:

nohup /home/oracle/import.sh 1> out.log 2> out.err


and it worked! Thanks a lot!

[Jorge Fabregas]

Hello everyone,

Thanks for your help.

Steve! THANKS! That was it! Redirecting stderr!!!

It seems that nohup will only redirect stdout (to nohup.out) but it doesn't redirect stderr.

I run the script as:

nohup /home/oracle/import.sh 1> out.log 2> out.err


and it worked! Thanks a lot!

[Andrew Cowan]

One other problem caused by backgrounding jobs is when the process is attempting to talk directly to a psuedo tty device. A good demonstration of this is if you "nohup" the cu command. It will seem to keep running but the number of OS interrupts will go through the roof, as the process spirals out of control.

Great care should always be excerised when backgrounding any interactive program, as the results can be quite spectacular, and in extreme cases can even crash your entire system.