Running Oracle Linux 6 (derivative of RHEL 6)
Given this snippet of code in a shell script:
#-- reset oratab to use 11.2 home for dwdev
#-- normally we'd just use sed to do this sort of thing, but that would
#-- require permissions that we don't have in the /etc/ directory, so we
#-- use 'ed' instead.
echo =======================================================
echo `date +%Y-%m-%d" "%H:%M:%S` - Modifying /etc/oratab
echo Original oratab entry for dwdev:
grep ^dwdev /etc/oratab
ed -s /etc/oratab <<EOF
,s|dwdev:/u01/app/oracle/product/12.1.0.2/dbhome_1:N|dwdev:/u01/app/oracle/product/11.2.0.4/dbhome_1:N|
w
q
EOF
echo New oratab entry for dwdev:
grep ^dwdev /etc/oratab
The output looks exactly as I expect, and the rest of the script, that is depending on these settings, behaves exactly as planned. Here's the output through that section:
2017-05-19 12:51:28 - Modifying /etc/oratab
Original oratab entry for dwdev:
dwdev:/u01/app/oracle/product/12.1.0.2/dbhome_1:N# line added by Agent
New oratab entry for dwdev:
dwdev:/u01/app/oracle/product/11.2.0.4/dbhome_1:N# line added by Agent
However, when the script is complete, I go back and check the contents of the subject file (/etc/oratab) and it is back to its original:
oracle:dwdev$ grep ^dwdev /etc/oratab
dwdev:/u01/app/oracle/product/12.1.0.2/dbhome_1:N # line added by Agent
The rest of the script is pretty lengthy and involved, but I see nothing else in it that could conceivably modify the file /etc/oratab
From the output you have shown us, it appears that ed is doing what you requested. So, if the contents of /etc/oratab have gone back to their original state when the script terminates, it would seem likely that has modified the file.
If the command:
grep oratab scriptname
where scriptame is the name of the file containing your shell script doesn't show any output other than:
echo `date +%Y-%m-%d" "%H:%M:%S` - Modifying /etc/oratab
echo Original oratab entry for dwdev:
grep ^dwdev /etc/oratab
ed -s /etc/oratab <<EOF
echo New oratab entry for dwdev:
grep ^dwdev /etc/oratab
then one might guess that:
- something in your script invokes another command that resets
/etc/oratab 's contents,
- there is another directory entry hard-linked to
/etc/oratab and your script is modifying the file using a different filename,
- there is another file that is a symbolic link pointing to
/etc/oratab and your script is modifying the file using the name of one of those symbolic links, or
- some other script is asynchronously changing the contents of
/etc/oratab that seems to run consistently between the time the second grep in your code shows that the file changed and the time when you notice that the contents have reverted to their original contents after your script terminates.
1 Like
Don - thanks for the reply. Except for the idea of the links, that what I would have thought. Since this is a vm I build myself, I know there are no links involved, nothing else in the script to modify the file, and no other scripts running. In cutting down the script for a 'proof demo' with lots of debugging 'echo' messages, I do find that the change happens during/after invoking sqlplus to shut down the database. At that point, probably best if I take the issue to an Oracle forum. I'll post back here what I find out, to give closure to the thread.
1 Like
Confirmed, issue is a background task involved with Oracle Grid Infrastructure.