I came across an interesting situation related to an upgrade
of Red Hat. Due to planned upgrades of
Oracle 10g to 11g, we are first performing upgrades of RH from 4.x to 5.x. Normally an OS upgrade would involve sanity checks that nothing breaks, but
you'd expect your basic Unix commands to behave the same.
Yet after running a few DBA maintenance scripts I found a
problem with one script that was using "fuser". Our script checks a list of files to see if
any are currently open and if so, it processes them differently. The problem was that under RH 5.x (5.3,
specifically), where "fuser" piped to "cut":
for active_file in `fuser $dir/$sub/* 2>&1 |
cut -d\: -f1`
In the snipet of code above under RH 5.3, it appeared that
both files and the PID from "fuser" were getting returned, as if
"cut" didn't work at all.
After closer investigation it turned out that "fuser" was the
guilty party. I ran a simple test on a
database server with Oracle running, knowing that "libclntsh*" would
be open.
Using the command:
fuser $ORACLE_HOME/lib/libclntsh* | cut -d\: -f1
… under RH 4 you'll get:
/ora01/app/oracle/product/10.2.0/db_1/lib/libclntsh.so
/ora01/app/oracle/product/10.2.0/db_1/lib/libclntsh.so.10.1
… while under RH 5 you'll get:
/ora01/app/oracle/product/10.2.0/db_1/lib/libclntsh.so:m
/ora01/app/oracle/product/10.2.0/db_1/lib/libclntsh.so.10.1:m
7309 7309
I did a crazy thing and checked the "man" pages
for "fuser" to see if I was missing something and sure enough, I was:
a change in RH 5! See the following line
listed right before the OPTIONS
section:
fuser outputs only the PIDs to
stdout, everything else is sent to stderr.
That explains the difference in behavior between releases. Fortunately the workaround is easy: redirect
stderr to stdout.
Fortunately I caught this, but I wonder what other changes
are lurking out there?
