haugj@pigs.UUCP (Joe Bob Willie) (09/01/88)
In article <12017@steinmetz.ge.com> davidsen@crdos1.UUCP (bill davidsen) writes: > I wouldn't claim that uucp on early versions (like 2.1.2) were >pretty grim, but the "Telebit" uucp is solid as far as I can tell. I >would be lieve that many sites can't support news due to disk space. i am currently having trouble on three systems i administer with LCK.. files for the terminals getting nuked. one of the systems runs the "telebit" uucp. the others don't (because they don't run xenix). so there seems to be some collection of problems, but at least they are common problems (1/2 :-) -- =-=-=-=-=-=-=-The Beach Bum at The Big "D" Home for Wayward Hackers-=-=-=-=-=-= Very Long Address: John.F.Haugh@rpp386.dallas.tx.us Very Short Address: jfh@rpp386 "ANSI C: Just say no" -- Me
daveh@marob.MASA.COM (Dave Hammond) (09/02/88)
In article <385@pigs.UUCP> haugj@pigs.UUCP (Joe Bob Willie) writes: >i am currently having trouble on three systems i administer with LCK.. >files for the terminals getting nuked. one of the systems runs the >"telebit" uucp. the others don't (because they don't run xenix). Funny you should mention nuked LCK.. files. I just began noticing the same thing on a system which just got updated with the TeleBit uucp. In this case the problem occurs when non-uucp communications programs (such as Kermit, ProComm or `CU') placed the LCK.. files there. The new uucico (having been started from some daemon) seems to disbelieve these `foreign' LCK.. files and unlinks them. I've also noticed a nasty little `feature' of both the TeleBit and older uucico programs. If the aforementioned foreign comm program has set a lock on tty1a, and uucico is started up on tty1A -- you will see a quick `+++' and then an `ATH0', and you find yourself staring at `NO CARRIER'. Hmmm. Dave Hammond UUCP: {uunet|...}!marob.masa.com!!daveh DOMAIN: daveh@marob.masa.com ------------------------------------------------------------------------------
wnp@dcs.UUCP (Wolf N. Paul) (09/02/88)
In article <394@marob.MASA.COM> daveh@marob.masa.com (Dave Hammond) writes: >In article <385@pigs.UUCP> haugj@pigs.UUCP (Joe Bob Willie) writes: >>i am currently having trouble on three systems i administer with LCK.. >>files for the terminals getting nuked. one of the systems runs the >>"telebit" uucp. the others don't (because they don't run xenix). >Funny you should mention nuked LCK.. files. I just began noticing the >same thing on a system which just got updated with the TeleBit uucp. >In this case the problem occurs when non-uucp communications programs >(such as Kermit, ProComm or `CU') placed the LCK.. files there. The >new uucico (having been started from some daemon) seems to disbelieve >these `foreign' LCK.. files and unlinks them. I believe that's because of the way UUCP-related programs determine the validity of lock files. Pre-HDB versions (under Sys V, don't know for sure about Xenix) write (a) their PID in a binary format ( write(fd,&PID, sizeof(PID)) ) into the lock file, and (b) touch the lockfile regularly to make sure it doesn't grow older than (I think) an hour. Other programs are supposed to either check the age of the lockfile, or otherwise (if available on your system) use the syntax kill(PID, 0) to determine if the process owning the lock file is still alive. HDB uucp doesn't care about the age of the lock files, but uses an ASCII-format PID (fprintf(fp, "%10.10d\n", PID)) to identify the owner of a lock file, and then determines the validity of that PID by means of kill(PID,0). Most of the non-uucp communications programs I have come across have very weak lockfile handling, and do not conform to either of these rules. If you use the cu that came with your system, and the uucico that came with your system, they should cooperate. If you acquired a different uucico (i.e. Trailblazer), you might want to check what format the LCK..* files are it creates -- od -c might do that. If the cu (old) uses binary PIDS and the uucico (new) uses ASCII PIDS, you will see the symptoms you describe above. You need to pester your vendor for a compatible version of cu. If you use kermit, or pcomm, or any other public-domain comm program, try to get source and fix it. Sorry I don't know how lockfiles would be handled in a DOS-under-UNIX environment, which is the only way to run ProComm -- but again, I suspect that the lockfile format is incompatible. The "+++" and "ATH" is legitimate. uucico has just tried to call once, and has been unsuccessful because the modem, being otherwise occupied, did not dial, or otherwise respond in a way uucico recognizes. So uucico tries to hang up (which is what you see), and attempts to call again. You probably should have seen the dial command from uucico a little while before the hangup -- if you missed it, it's probably because it had less drastic results than the hangup command. -- Wolf N. Paul * 3387 Sam Rayburn Run * Carrollton TX 75007 * (214) 306-9101 UUCP: killer!dcs!wnp ESL: 62832882 DOMAIN: dcs!wnp@killer.dallas.tx.us TLX: 910-380-0585 EES PLANO UD
chip@vector.UUCP (Chip Rosenthal) (09/02/88)
In article <394@marob.MASA.COM> daveh@marob.masa.com (Dave Hammond) writes: >In article <385@pigs.UUCP> haugj@pigs.UUCP (Joe Bob Willie) writes: >>i am currently having trouble on three systems i administer with LCK.. > >the problem occurs when non-uucp communications programs >(such as Kermit, ProComm or `CU') placed the LCK.. files there. Strange. I've written my own comm program, and I've never seen this problem. Do these things create proper lock files, i.e. containing the PID of the lock owner? >older uucico programs. If the aforementioned foreign comm program >has set a lock on tty1a, and uucico is started up on tty1A... My solution has been to lock both tty1A and tty1a. On the flip side, it's a really good idea for a comm program to check /etc/utmp as well as the lock files. With dialin/dialout lines, you can step on a dialin unless you first verify that the line is unused. -- Chip Rosenthal chip@vector.UUCP | I've been a wizard since my childhood. Dallas Semiconductor 214-450-0486 | And I've earned some respect for my art.
jbayer@ispi.UUCP (id for use with uunet/usenet) (09/03/88)
In article <394@marob.MASA.COM>, daveh@marob.MASA.COM (Dave Hammond) writes: > > I've also noticed a nasty little `feature' of both the TeleBit and > older uucico programs. If the aforementioned foreign comm program > has set a lock on tty1a, and uucico is started up on tty1A -- you > will see a quick `+++' and then an `ATH0', and you find yourself > staring at `NO CARRIER'. Hmmm. Xenix (and I suspect many other Unixs) is stupid. It doesn't know that tty1a and tty1A both refer to the same device. If you look at the spool directory you will see the names of the lock files include the device name. Because of the case dependancy uucico will not realize that they both are refering to the same device. Although I don't have the sources, I would suspect it to be a fairly simply patch to make uucp ignore case when looking at lock files. Hey SCO, are you listening?? Jonathan Bayer Intelligent Software Products, Inc. 19 Virginia Ave. Rockville Centre, NY 11570
zeeff@b-tech.UUCP (Jon Zeeff) (09/04/88)
In article <173@ispi.UUCP> jbayer@ispi.UUCP (id for use with uunet/usenet) writes: > Xenix (and I suspect many other Unixs) is stupid. It doesn't >know that tty1a and tty1A both refer to the same device. If you look at >the spool directory you will see the names of the lock files include >the device name. Because of the case dependancy uucico will not realize >that they both are refering to the same device. One solution is to use the same name (tty1a), but put one somewhere other than /dev (let's say /dev/x/tty1a). Programs can them refer to /dev/tty1a or /dev/x/tty1a, depending on what they want to do. The lock files don't store the directory name, so it works fine. Note that this same trick solves some permission problems. Getty and uucp reset the permissions on a line that you might want to be r/w group staff. Creating another device with the same name works fine. -- Jon Zeeff Branch Technology, umix!b-tech!zeeff zeeff%b-tech.uucp@umix.cc.umich.edu
biburger@quando.UUCP (Wolf-D. Biburger) (09/22/88)
In article <193@dcs.UUCP> wnp@dcs.UUCP (Wolf N. Paul) writes: >In article <394@marob.MASA.COM> daveh@marob.masa.com (Dave Hammond) writes: >>In article <385@pigs.UUCP> haugj@pigs.UUCP (Joe Bob Willie) writes: >>(such as Kermit, ProComm or `CU') placed the LCK.. files there. The >>new uucico (having been started from some daemon) seems to disbelieve >>these `foreign' LCK.. files and unlinks them. the problem may also occur, if those programs (kermit etc.) place the 'LCK..'-files in '/usr/spool/uucp/' but 'uucico' in '/usr/spool/uucp/LCK/' >I believe that's because of the way UUCP-related programs determine the >validity of lock files. I don't think so - there are instructions inside the programs, to check the existance of the 'LCK..'-file, but not any contents of it. those 'LCK..'-files work as a semaphor (see the name....) and if they exist a long time there may get up a 'uuclean'-process, to check the age of all files in '/usr/spool/uucp/' see '..../crontab' -- "Wolf-Dieter Biburger" Uad- biburger@quando.UUCP Off- Quantum GmbH / E-Figge-Str. 83 / D-4600 Dortmund 50 / (49) +231 75 44 1 00 Prv- Am Spoerkel 61 / D-4600 Dortmund 50 / +231 75 41 03
james@bigtex.uucp (James Van Artsdalen) (09/23/88)
In article <641@quando.UUCP>, biburger@quando.UUCP (Wolf-D. Biburger) wrote: > I don't think so - there are instructions inside the programs, to > check the existance of the 'LCK..'-file, but not any contents of it. No. > those 'LCK..'-files work as a semaphor (see the name....) and > if they exist a long time there may get up a 'uuclean'-process, Not correct on modern UUCPs (perhaps true for old ones though). The contents of the LCK.. file are significant. In HDB uucp the contents correspond to the printf control string "%10d\n" and the content id the PID of the locking process. Other processes use the content to determine if the lock is valid by using kill(PID, 0) and checking for an error. Therefore, invalid contents of the lock file will cause an invalid PID to be read, which will prevent the locking process from being found by kill(), and uucico will remove the lock. Older UUCPs did not use the (relatively new) capability of kill to detect the existence of a process, and hence simply assumed that a lock was "stale" if it was old enough. "Old enough" often meant an hour or two. This scheme doesn't terribly well. -- James R. Van Artsdalen ...!uunet!utastro!bigtex!james "Live Free or Die" Phone: 512-346-2444 10926 Jollyville Rd #901 Austin TX 78759