Return to BSD News archive
Xref: sserve comp.bugs.4bsd:1949 comp.os.386bsd.bugs:573 Newsgroups: comp.bugs.4bsd,comp.os.386bsd.bugs Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!saimiri.primate.wisc.edu!zaphod.mps.ohio-state.edu!cs.utexas.edu!wotan.compaq.com!moxie!hackney From: hackney@moxie.hou.tx.us (Greg Hackney) Subject: Re: flock broken - I could use some help Organization: Home References: <C5t8wH.Hs@moxie.hou.tx.us> <1993Apr21.184636.1121@cs.few.eur.nl> <1993Apr26.170501.12617@cs.few.eur.nl> Message-ID: <C647Mx.LKI@moxie.hou.tx.us> Date: Mon, 26 Apr 1993 23:52:05 GMT Lines: 29 pk@cs.few.eur.nl (Paul Kranenburg) writes: > The problem is a dangling pointer left in the lockf structure > Unfortunately, the fix that went with it was totally bogus. This one might > do a better job: >--- ufs/ufs_lockf.c Mon Apr 26 18:55:57 1993 Paul, Mark suggested that I use the 386BSD ufs_lockf.c code that you just posted. It seems to work just fine. Thanks. This bugger has been causing problems for some time. The mail transport agent Smail3.1.28 uses flock quite a bit. If it's attempting to connect to another site, or actually delivering email to a site, it locks out any other Smail processes from delivering at the same time. The secondary process alarms out after a while, and BANG, you're dead. This was really frequent for my email gateway, since so many sites get their mail via one flocked() site, UUnet. Also this cropped up in the LPR/LPD printer package. The 'lprm' command goes out over the network to a remote print server, which has a lpd daemon running with an flock() on the printer. The remove command kills the lpd daemon. The originating lprm command sends a restart to the remote printer to start a new lpd process for that printer, using flock(). However, the old one may not have died yet and not released the lock. BANG, the print server is dead. -- Greg Hackney hackney@moxie.hou.tx.us