Blog dedicated to Oracle Applications (E-Business Suite) Technology; covers Apps Architecture, Administration and third party bolt-ons to Apps

Wednesday, February 6, 2008

Unable to open file for reading: marker1.txt

While merging 255 functional patches with admrgpch, we got the following error:

AD Merge Patch error:
Unable to open file for reading:

/patchtop/source/5522715/marker1.txt

A truss of the admrgpch command showed that it is failing as soon as open files reaches 256:
openat(-3041965, "/stage/jul_2008/gpshpc76/func_patches/before/5522715", O_RDONLY|O_NDELAY|O_LARGEFILE) = 255
fcntl(255, F_SETFD, 0x00000001) = 0
fstat64(255, 0xFFBF55F0) = 0
close(255) = 0
openat(-3041965, "/stage/jul_2008/gpshpc76/func_patches/before/5522715", O_RDONLY|O_NDELAY|O_LARGEFILE) = 255
fcntl(255, F_SETFD, 0x00000001) = 0
fstat64(255, 0xFFBF1068) = 0
getdents64(255, 0xFE604000, 8192) = 264
open("/stage/jul_2008/gpshpc76/func_patches/before/5522715/marker1.txt", O_RDONLY) = 256
close(256) = 0
fstat64(2, 0xFFBF03F0) = 0

AD Merge Patch error:
Unable to open file for reading:
write(2, "\n A D M e r g e P a".., 56) = 56

write(2, "\n", 1) = 1
/stage/jul_2008/gpshpc76/func_patches/before/5522715/marker1.txtwrite(2, " / s t a g e / j u l _ 2".., 64) = 64

write(2, "\n", 1) = 1
write(3, "\n * * * * * * * * * * *".., 437) = 437
close(3) = 0
_exit(1)

However the soft and hard limit are set to 65535 on the OS.

So as a workaround we removed 6 patches from the 255 patches and it merged fine. I have logged an SR with Oracle for a resolution. Still not happy with the situation, I was googling for solution and found an article : Solaris OS Solutions to 32-Bit stdio's 256 File-Descriptors Limitation.

Historically, 32-bit applications running on the Solaris Operating System (OS) have been limited to using only the file descriptors 0 through 255 with the standard I/O functions in the C library. The extended FILE facility on Solaris 10 OS and later versions allows well-behaved 32-bit applications to use any valid file descriptor with the standard I/O functions.

A well-behaved application is one that meets all three of the following requirements:

* Does not directly access any member fields in the FILE structure pointed to by the FILE pointer associated with any standard I/O stream
* Checks all return values from standard I/O functions for error conditions
* Behaves appropriately when an error condition is reported

This article explains in detail the runtime and programming solutions that were introduced under the extended FILE facility. The following discussion is relevant only in 32-bit applications, as 64-bit applications are immune to the limitation to 256 file descriptors.

This is what I did as suggested in the article:

$ ulimit -n 65536 (My ulimit was already on 65536)

$ ulimit -n
65536

$ LD_PRELOAD_32=/usr/lib/extendedFILE.so.1
$ export LD_PRELOAD_32
$ admrgpch -s source -d destination -merge_name bigpatch

And it succeeded without issues:

0 copy drivers merged.
0 database drivers merged.
0 generate drivers merged.
257 mixed drivers merged to a unified driver.

Patch merge completed successfully

Now I'll close the SR I had opened with my observations.

No comments: