From: utzoo!decvax!harpo!floyd!cmcl2!philabs!mcvax!ukc!pc Newsgroups: net.unix-wizards Title: Possible file table kernel problem Article-I.D.: ukc.1407 Posted: Wed Mar 2 15:18:42 1983 Received: Fri Mar 11 05:49:52 1983 We run 4.1BSD and have installed several device drivers to support our Cambridge ring. Typically, a /dev/entry is mapped in a dynamic way onto a printer (say) on our network. Most of the time, the device driver functions perfectly, but there seems to be occasions (about one every two or three days - when the ring interface is in continual use) where the close routine in the driver isn't called. The program which drives the printer opens it as standard output and the forks to pr to actually do the printing. So the file table entry for the device has a reference count of two - but there is only one inode entry in memory. Now, sometime during the closedown of this pair of processes a user sends an interrupt signal to the parent. The parent traps this (using sigset) and passes on an interrupt to the child. I suspect (but can't prove) that this signal either causes some form of screw-up in the file table mechanism such that the code to call the close routine doesn't happen - or what...? There are two places (sys1.c, sys3.c) where the call to closef is not of the form fp = u.u_ofile[i]; u.u_ofile[i] = NULL; closef(fp); Is this the problem????? At the end of the day, the file table entry and the inode referenced by it have gone - but the device is locked because it's internal tables say that it is busy. The evidence is that the close routine has never been called. Has anyone out there in uucp-land experienced this sort of problem? Please don't just dismiss it and say OH it must be the device driver because I have looked and looked and looked and looked. If anyone has had this problem and can give me a fix (or just to say they might have had it) - please reply to lime!ukc!pc (best) or philabs!mcvax!ukc!pc or decvax!mcvax!ukc!pc Peter Collinson, University of Kent UK