Open File status

[Jakes Louw]

I'm getting a weird one from an application program:
"BLPREP_07_22168_20031010221241.log:*** I/O error in file /q01ol2/opern/tlg_var/tsa/bl/temp/Sep/24/bl.070920030135NW1cycls.20030924.temp while trying to OPEN FILE, status is 9. (BLBN_CYLSI)"

I'm getting nothing else from SYSLOG or DMESG.
The kernel is set as follows:
maxfiles = 2048
maxfiles_lim = 4096
nfile = 43878
nflocks = 200

Now, it COULD be one of the above, but surely I'd get something more meaningful than "status 9", or is this programmer just intercepting the OS error and passing on his own interpretation?

[Mark Grant]

Well, HPUX error 9 is "Bad file number" which could mean you have exceeded a kernel tunable such as you suggest but that might have nothing to do with the 9 the application programmer is thinking about. If it was a tunable you are exceeding, you wouldn't really expect it to always be the same file or application that was experienceing the problem.

It might be that the directory or filesystem in which these files appear is corrupted or the underlying disk is having a bit of a problem.

If it is always in this filesystem, I would consider a quick symbolic link to make these files get created in another volume group somewhere, just to rule out disk/filesystem issues.

[Jakes Louw]

Well, about all I can do then is run and fsck and fsadm with some options, I suppose?

An underlying disk problem it definitely is not: this is a 450 GB filesystem striped across 30 x 15 GB EMC RAID 1/0 LUNs.
An extent and fragmentation report shows no problems.
I always assumed that VxFS filesystems had no upper limit on inodes. Am I wrong? I assumed that the VxFS filesystem had a dynamic inode table.

If I'm hitting a system constraint, it WOULD be nice for glorious HP-UX to sort of point me somewhere......

[Mark Grant]

You are certainly correct about the inode issue , they are created on the fly with vxfs. Ok, disk issue it almost certainly isn't but you can still get I/O errors from the filesystem/logical volume so I would at least attempt to get these files written somewhere else for a while.

You could try strings/cat on them to see if you can reproduce the error out of the application and if you can't then point the finger at the developer.

[Jakes Louw]

Files have been checked: they are all fine.
Linking to another area is going to be a pain, but I'll try that.

[A. Clay Stephenson]

This is almost certainly an application error and has nothing to do with the OS. The glaring problem is that the open() system call does not set errno to EBADF (9) (man 2 open for details) so that at best the error message indicates sloppy user message creation. I suspect that what happened, is that the programmer assumed open was ok and then attempted a write(), read(), lockf(), fcntl(), or lseek() -- all of which could set errno to EBADF. You really need to contact the developer and ask him how open() could set errno to EBADF.