File Table Corruption?
Mr. Nice Guy
In processing the /etc/shadow file, we got the following output one
time from one of our scripts:
omp-d@pciexbus/pciexdev/pciexfn;
::::::::::::::::# 272 "../common/pciex.esc"
::::::::engine serd.io.pciex.flt-nf-u@pciexbus/pciexdev/pciexfn
N=3,T=1week,method=persistent,trip=ereport.io.pciex.flt-nf-u@pciexbus/
pciexdev/pciexfn;
::::::::# 276 "../common/pciex.esc"
::::::::event upset.io.pciex.flt-nf-u@pciexbus/pciexdev/pciexfn
engine=serd.io.pciex.flt-nf-u@pciexbus/pciexdev/pciexfn;
::::::::# 279 "../common/pciex.esc"
::::::::prop error.io.pciex.flt-nf-u@pciexbus/pciexdev/pciexfn(1)-
>ereport.io.pciex.flt-nf-u@pciexbus/pciexdev/pciexfn;
::::::::# 282 "../common/pciex.esc"
::::::::prop error.io.pciex.flt-nf-u@pciexbus/pciexdev/pciexfn(0)-
>error.io.pciex.flt-nf-ecrcreq-u@pciexbus/pciexdev/
pciexfn,error.io.pciex.flt-nf-ecrccomp-u@pciexbus/pciexdev/
pciexfn,error.io.pciex.flt-nf-p
The script is supposed to loop over the shadow file and update a
single field of that file. The "::::::::" are expected, though there
should be some values. The last bit of information on the line looks
like it was taken from the fault management system, though the only
files open in this script at that time are /etc/shadow and the
temporary file copied from /etc/shadow.
If it matters, it was a Perl script. It's a simple "for each line in
this file, if the user id matches a pattern, update this line, else,
write this line untouched."
In tracking down the odd fault management data at the end of the line,
I see in the /proc file system that there are files in the /fd
directory of a particular process - /proc/9878/fd/42, for example -
that contain information along the lines of the above. PID 9878
corresponds to /usr/lib/fm/fmd/fmd, currently, on my host. The
contents of /proc/9878/fd/42 are not an exact match, but is it
possible that, during the processing of my script, or shortly before,
my system could have experienced a hardware fault of some sort
corrupting the internal file pointers for my process causing them to
point to another process's open files, leading to this output?
I realize it's a long shot, but a system fault - transient RAM? PCIex
failure? power fluctuation? - could potentially cause this kind of
weirdness, right? Unfortunately, I did not save the fault management
logs so I can't tie this to a particular event. It has happened only
once on this machine, however, though the shadow management script
runs daily and every time the system is rebooted.
Thanks for any input.
Aaron