Path: utzoo!utgpu!watserv1!watmath!att!ll1a!cuuxb!mmengel From: mmengel@cuuxb.ATT.COM (~XT6561110~Marc Mengel~C25~M27~6184~) Newsgroups: comp.unix.questions Subject: Re: uugetty & lock files Summary: a lock file doesn't mean its locked... Message-ID: <5170@cuuxb.ATT.COM> Date: 12 Sep 90 15:15:04 GMT References: <384@fe2o3.UUCP> Reply-To: mmengel@cuuxb.UUCP (Marc W. Mengel) Organization: AT&T National Technical Support Center Lines: 40 In article <384@fe2o3.UUCP> michael@fe2o3.UUCP (Michael Katzmann) writes: >This program looks to see if a lockfile is present /usr/spool/locks/LCK..tty1, >before blindly writting out to the line. > >The problem: > uugetty seems to create a lockfile ... >Any ideas anyone? Your confusion is common; actually a uucp lock file is only valid if the process whose id is written in the lock file is still running. What usually happens is that a uugetty sees some data, locks the port to let someone log in, then times out and exits, and a new uugetty is respawned. The LCK..ttyxx file lis left there, but has the process id of the old uugetty in it. This is important to have happen because a uugetty will exec a login who will exec a shell, none of whom have any idea the lock file is there; but they still need it locked. Since they are exec-ed however, they will have the same process id and the lock will be valid. To check if a uucp lock file is valid you have to read the pid from the file, and try a kill(pid,0) to see if the process exists. If it doesn't, you unlink() the lock file and open(...O_EXCL) your own, and write your own pid in it. On the other hand, to do things like chat with a modem, you can write a real simple shell script with "cu" (which knows all the lock file conventions, etc.) by just doing something like: +----------------------- |cu -l /dev/ttyxx <