On 16 Jun, Tim Robbins wrote: > On Mon, Jun 16, 2003 at 04:09:51PM +1000, Tim Robbins wrote: > >> On Sun, Jun 15, 2003 at 08:43:15PM -0400, Chris Shenton wrote: >> >> > I've been running qmail for years and like it, installed pretty much >> > per www.LifeWithQmail.org. My main system was running FreeBSD >> > 5.0-RELEASE and -CURRENT and qmail was fine. When I just upgraded to >> > 5.1-CURRENT a couple days back, the qmail-send process started using >> > all CPU. >> >> This looks like a bug in the named pipe code. Reverting >> sys/fs/fifofs/fifo_vnops.c to the RELENG_5_0 version makes the problem go >> away. I haven't tracked down exactly what change between RELENG_5_0 and >> RELENG_5_1 caused the problem. > > Looks like revision 1.86 works, but it stops working with 1.87. Moving the > soclose() calls to fifo_inactive() may have caused it. This is an interesting observation, but I'm not sure why it would make a difference. I haven't looked at the qmail source, but it looks like it is doing a non-blocking open on the fifo, calling select() on the fd, and hoping that select() waits for a writer to open the fifo before returning with an indication that the descriptor is readable. It looks like the select code is calling the soreadable() macro to determine if the fifo descriptor is readable, and the soreadable() macro returns a true value if the SS_CANTRCVMORE socket flag is set, which would indicate an EOF condition. I might believe that I accidentally changed the setting of this flag, but I just compared fifo_vnops.c rev 1.78 with 1.87 and I believe this flag should be set the same way in both versions. In both versions, fifo_close() always calls socantrcvmore(), which sets SS_CANTRCVMORE when the writer count drops to zero. Prior to 1.87, fifo_close() also destroyed the sockets when the reference count dropped to zero, which caused fifo_open() to recreate the sockets when the fifo was opened again, and when it did, fifo_open() set the SS_CANTRCVMORE flag again. The posted qmail syscall trace looks like what I would expect to see in the present implementation. I can't explain why it would behave any differently prior to 1.87 ...Received on Sun Jun 15 2003 - 22:39:32 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:12 UTC