Strange Ctrl+C behavior

Shell Programming and Scripting
1

Hello All,
I have a strange issue. I've created a shell script which connects to RMAN (Oracle Recovery Manager) and executes full DB backup. I then executed this script with nohup and in the background:

$ nohup my_script.sh > logfile.log 2>&1 &

The issue is that when I tried to take a look into the log:

tail -f logfile.log

and press Ctrl+C to exit from the tail command I am back in the shell prompt but at the same time RMAN put in the log:

user interrupt received

I'm not able to understand why RMAN receives the Ctrl+C. Please help me.

Jacek

2

Depends on the contents of my_script.sh.

3

My script was:

#!/bin/bash
export NLS_DATE_FORMAT="YYYY-MM-DD HH24:MI:SS"
export ORACLE_SID=AGMISMP
rman target / <<EOF
BACKUP  INCREMENTAL LEVEL 0  DATABASE  FORMAT '/%d/DBF-FULL_%s_%U_%T'    TAG 'IPM-11618809'  KEEP UNTIL TIME 'sysdate+100'  RESTORE POINT IPM11618809;
EOF
4

Any update?

5

The only possible explanation that comes to mind is somehow the nohup ped process clinches to the terminal of its parent process. True, nohup should prevent exactly this, but it is the only way what you said could happen. My gut feeling (without being able to prove that, but you might investigate in this direction) is that in fact the rman binary isn't honoring the request to relinquish the terminal correctly. This would also explain why the complaint comes from there.

The following is not really a solution (for this you probably have to contact Oracle and admonish them for their sloppy programming) but may be a workaround: start the script via an at -job, like this:

echo "my_script.sh > logfile.log 2>&1" | at <sometime>

at , like cron , doesn't provide its parent process a terminal in first place which it could fail to release. Notice, though, that you might have to set more of a working environment than you did now, because your script inherits from your current environment now but would only inherit from init if called from cron / at . init is notoriously poor when it comes to environment.

I hope this helps.

bakunin

6

Thanks for the reply, bakunin.
I forgot to tell that "nohup my_script.sh..." is executed inside parent shell script, which was used to prepare my_script.sh
Does this change anything? :rolleyes:

7

As it is i already suspected that, so: no, that doesn't change anything.

It is like this: when you start a login shell a "terminal" is created (by a process called getty or something analogous). This terminal is part of the process environment of your login session and is then "inherited" thoughout the process tree originating in your login session. That is, whatever you start from there - foreground processes, background processes, ... - will always use this terminal for any (not-redirected) output. As soon as this terminal ceases to exist (i.e. you log off) all the other processes using this terminal too will also be terminated, because they too lose their terminal.

Now, you might want to have processes continue to run without your session remaining - in fact, this is what most applications are supposed to do: they should continue to run even if the session where they are started ends. One needs a way of telling a process that "yes, there is a terminal, but don't care if it goes away".

For exactly this purpose there is nohup ("no termination on hangup") and this is what it does. Still: this only works if the program honours it (that is: there needs to be some part in the code dealing with it) and second: it doesn't matter if the process is started froma script or by hand: this influences only where in the process tree it is located. Since the purpose of nohup is solely to "disown" the process it doesn't matter how it would otherwise inherit something (the terminal) it now won't.

I hope this explains it.

bakunin