root@libove.UUCP (Jay M. Libove) (10/08/88)
[ I posted something about this before, but got little response, and I have reason to believe it died before going too far from my site ] I have a SCO Xenix 80286 v2.2.1 system, and it has one modem, which I use for manual dial out as well as automatic dial out for UUCP connections. While I am using it manually, if a cron job comes up that calls /usr/lib/uucp/uucico, the LCK.. file in /usr/spool/uucp/ will be ignored and I will get the modem commands being fired out on the line while I am connected over it! As yet, this has beena nuisance, but I suppose it stands to be damaging eventually. I'm running the distribution SCO Xenix system, C-Kermit 4E070 (which creates /usr/spool/uucp/LCK..ttyxx when you allocate ttyxx), and the SCO enhanced uucico for telebit trailblazer modems (though I have just a normal modem - I needed the ability to send BREAKs). Is this correct behaviour? I was under the impression that C-Kermit used the LCK.. files because the uucp software had started that convention, and now here is uucp ignoring it! Thanks in advance! -- Jay Libove ARPA: jl42@andrew.cmu.edu or libove@cs.cmu.edu 5731 Centre Ave, Apt 3 BITnet: jl42@andrew or jl42@drycas Pittsburgh, PA 15206 UUCP: uunet!nfsun!libove!libove or (412) 362-8983 UUCP: psuvax1!pitt!darth!libove!libove
mercer@ncrcce.StPaul.NCR.COM (Dan Mercer) (10/11/88)
In article <171@libove.UUCP> root@libove.UUCP (Jay M. Libove) writes:
:
:[ I posted something about this before, but got little response, and I
: have reason to believe it died before going too far from my site ]
:
:I have a SCO Xenix 80286 v2.2.1 system, and it has one modem, which I
:use for manual dial out as well as automatic dial out for UUCP connections.
:
:While I am using it manually, if a cron job comes up that calls
:/usr/lib/uucp/uucico, the LCK.. file in /usr/spool/uucp/ will be ignored
:and I will get the modem commands being fired out on the line while I
:am connected over it! As yet, this has beena nuisance, but I suppose it
:stands to be damaging eventually.
:
:I'm running the distribution SCO Xenix system, C-Kermit 4E070 (which
:creates /usr/spool/uucp/LCK..ttyxx when you allocate ttyxx), and the
:SCO enhanced uucico for telebit trailblazer modems (though I have just
:a normal modem - I needed the ability to send BREAKs).
:
:Is this correct behaviour? I was under the impression that C-Kermit used
:the LCK.. files because the uucp software had started that convention,
:and now here is uucp ignoring it!
:
:Thanks in advance!
:
:--
:Jay Libove ARPA: jl42@andrew.cmu.edu or libove@cs.cmu.edu
:5731 Centre Ave, Apt 3 BITnet: jl42@andrew or jl42@drycas
:Pittsburgh, PA 15206 UUCP: uunet!nfsun!libove!libove or
:(412) 362-8983 UUCP: psuvax1!pitt!darth!libove!libove
Two possibilities:
1. You have HoneyDanBer uucp, and the lock file is
is kept in a lock directory (I think its
/usr/spool/uucp/locks).
2. Your lock file no longer exists. If KERMIT does not
use the dial command, this is a strong possibility.
Dial will set an alarm to touch the lock file
at 45 minute intervals. Otherwise, a uucp cron
task will clean up old uucp file (including your
lock file). Next time it happens, try to
check your lock file. Or stay on for an hour and
see if your lock file still exists.
Dan Mercer
NCR Comtenwnp@dcs.UUCP (Wolf N. Paul) (10/11/88)
In article <171@libove.UUCP> root@libove.UUCP (Jay M. Libove) writes: >I have a SCO Xenix 80286 v2.2.1 system, and it has one modem, which I >use for manual dial out as well as automatic dial out for UUCP connections. >While I am using it manually, if a cron job comes up that calls >/usr/lib/uucp/uucico, the LCK.. file in /usr/spool/uucp/ will be ignored >and I will get the modem commands being fired out on the line while I >am connected over it! As yet, this has beena nuisance, but I suppose it >stands to be damaging eventually. There are two schemes used by different versions of uucp to determine if a lockfile is still valid or can be safely ignored. Older versions of uucp looked at the update time of the lockfile; the uucp software itself would keep touching the its lockfiles while they were valid, and if it found a "foreign" lockfile, it would delete it only if it had not been touched in a certain period of time. Don't know what that time period is, though. The newer version of uucp (and I don't know whether the Xenix TB version belongs here) looks at the lockfile's content to determine the PID of the process which created it. If that process is still active (determined by system call "kill(PID, 0)"), the lockfile is honored; if the process is no longer active, the lockfile gets deleted. My recollection of kermit's implementation of lockfiles is that it is very rudimentary: it does not touch its lockfiles regularly, and it does not put its PID into them, either in the old binary format, or in the newer "fprintf(lfp,"%10d\n", PID)" format. Therefore neither version of uucp, in my experience, KNOWS HOW TO honor kermit lockfiles. -- 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
jl42+@andrew.cmu.edu (Jay Mathew Libove) (10/12/88)
Oops! I posted about a problem with uucico ignoring extant lock files... BUT my lock file was for /dev/tty1a and the modem device is /dev/tty1A ... hee hee Unfortunately I can't get kermit to go out on the tty1A line, even though that is the modem control device! Anyone know how to get tty1A to let you talk out to the modem, and carry on a regular conversation via the modem? Thanks! Jay Libove ARPA: jl42@andrew.cmu.edu, libove@cs.cmu.edu 5731 Centre Avenue, Apt 3 BITNET: jl42@andrew Pittsburgh, PA 15206 UUCP: uunet!nfsun!libove!libove (412) 362-8983 UUCP: psuvax1!pitt!darth!libove!libove
rac@jc3b21.UUCP (Roger A. Cornelius) (10/12/88)
From article <171@libove.UUCP>, by root@libove.UUCP (Jay M. Libove): > > [ I posted something about this before, but got little response, and I > have reason to believe it died before going too far from my site ] > > I have a SCO Xenix 80286 v2.2.1 system, and it has one modem, which I > use for manual dial out as well as automatic dial out for UUCP connections. > > While I am using it manually, if a cron job comes up that calls > /usr/lib/uucp/uucico, the LCK.. file in /usr/spool/uucp/ will be ignored > and I will get the modem commands being fired out on the line while I > am connected over it! As yet, this has beena nuisance, but I suppose it > stands to be damaging eventually. -- > Jay Libove ARPA: jl42@andrew.cmu.edu or libove@cs.cmu.edu > 5731 Centre Ave, Apt 3 BITnet: jl42@andrew or jl42@drycas > Pittsburgh, PA 15206 UUCP: uunet!nfsun!libove!libove or > (412) 362-8983 UUCP: psuvax1!pitt!darth!libove!libove I've noticed the (almost) same thing on my system. I'm also using 2.2.1 on a 286 with the telebit utility files. I usually use a script which calls cu to dial out with, but at any rate, if uucico starts up while I'm using the line, it removes my LCK file, but then dies. It doesn't try to initalize the modem. The only reason I even noticed this was because I get a "Can't unlink LCK file" error when cu exits. Try dialing out with cu and see if you still get the initialization strings for the modem. I've only had uucp running shortly, so I'm not sure how things acted before I started using the telebit versions. Roger Cornelius -- +---------- Roger Cornelius -----------+ | (813)347-4399 | | ...gatech!codas!usfvax2!jc3b21!rac | +- ...gatech!usfvax2!jc3b21!rac -+
debra@alice.UUCP (Paul De Bra) (10/12/88)
In article <8XIceSy00Uo141M0UZ@andrew.cmu.edu> jl42+@andrew.cmu.edu (Jay Mathew Libove) writes: > >Anyone know how to get tty1A to let you talk >out to the modem, and carry on a regular >conversation via the modem? > Several modems have an option for pretending that CD is always on, except for a few seconds after disconnect. So first connect to your modem using tty1a and permanently select this option. Then you can start using tty1A. Hope this helps. Paul. -- |-------------------------- |debra@research.att.com | |uunet!research!debra | |--------------------------
john@jetson.UPMA.MD.US (John Owens) (10/13/88)
In article <8XIceSy00Uo141M0UZ@andrew.cmu.edu>, jl42+@andrew.cmu.edu (Jay Mathew Libove) writes: > Unfortunately I can't get kermit to go out on > the tty1A line, even though that is the modem > control device! > Anyone know how to get tty1A to let you talk > out to the modem, and carry on a regular > conversation via the modem? Here's what I do under SCO 2.2: /usr/lib/uucp/ungetty /dev/tty1A kermit -l /dev/tty1a .... /usr/lib/uucp/dialHA24 -h /dev/tty1A 2400 uucp won't dialout on the line after the ungetty, since it puts the "DIALOUT" entry in utmp. The dial -h (use whichever dial program is appropriate: see L-devices) both resets the modem nicely and does an ungetty -r to restart the getty. Good luck! -- John Owens john@jetson.UPMA.MD.US uunet!jetson!john +1 301 249 6000 john%jetson.uucp@uunet.uu.net
rac@jc3b21.UUCP (Roger A. Cornelius) (10/13/88)
From article <8XIceSy00Uo141M0UZ@andrew.cmu.edu>, by jl42+@andrew.cmu.edu (Jay Mathew Libove):
< Oops!
<
< I posted about a problem with uucico ignoring
< extant lock files... BUT my lock file was for
< /dev/tty1a and the modem device is /dev/tty1A
< ...
<
< hee hee
<
< Unfortunately I can't get kermit to go out on
< the tty1A line, even though that is the modem
< control device!
<
< Anyone know how to get tty1A to let you talk
< out to the modem, and carry on a regular
< conversation via the modem?
<
In my reply to your original posting, I talked about using cu. I've
since tried using kermit, (which won't use the uppercase modem port
here either), and uucico does remove the lockfile, but then dies
without disturbing my connection. I always use the uppercase tty
version when dialing out with cu with no problems. I have modified
my "dial" program for use with an error correcting - compressing modem,
but that shouldn't make a difference since dial is only invoked to do
the actual dialing. I'm using kermit 4E070 here also.
Roger Cornelius
--
+---------- Roger Cornelius -----------+
| (813)347-4399 |
| ...gatech!codas!usfvax2!jc3b21!rac |
+- ...gatech!usfvax2!jc3b21!rac -+thomas@uplog.se (Thomas Hameenaho) (10/13/88)
In article <171@libove.UUCP> root@libove.UUCP (Jay M. Libove) writes: > text deleted >While I am using it manually, if a cron job comes up that calls >/usr/lib/uucp/uucico, the LCK.. file in /usr/spool/uucp/ will be ignored >and I will get the modem commands being fired out on the line while I >am connected over it! As yet, this has beena nuisance, but I suppose it >stands to be damaging eventually. > Some uucp:s (BSD among others) use a directory for lock files. The lock file would in that case be /usr/spool/uucp/LCK/ttyxx. If that is your problem either recompile kermit or attack the binary with emacs (or any other editor that can handle binary files) and substitute /usr/spool/uucp/LCK.. with /usr/spool/uucp/LCK/^@.(The ^@ is a null character). -- Real life: Thomas Hameenaho Email: thomas@uplog.{se,uucp} Snail mail: TeleLOGIC Uppsala AB Phone: +46 18 189406 Box 1218 Fax: +46 18 132039 S - 751 42 Uppsala, Sweden
jamesd@lakesys.UUCP (James Dicke) (10/21/88)
>From article <171@libove.UUCP>, by root@libove.UUCP (Jay M. Libove): >> >> While I am using it manually, if a cron job comes up that calls >> /usr/lib/uucp/uucico, the LCK.. file in /usr/spool/uucp/ will be ignored >> and I will get the modem commands being fired out on the line while I >> am connected over it! As yet, this has beena nuisance, but I suppose it >> stands to be damaging eventually. If cu doesn't work there is one way that I know to take care of it all. I use a script to "disable /dev/ttyxx" before entering "cu" and then I "enable /dev/ttyxx" when finished. This prevents uucico from cutting in. I too run 286 version of Xenix (though its 2.2.3). __________________________________________________________________________ | overlord@abyss.UUCP | {backbone,uunet}!marque!lakesys!abyss!overlord | %|-----------------------+--------------------------------------------------| %| "God is omnipotent, omniscient, omnibenevolent- it says so right here on | %| the label." God is a trademark of AT&T Bell Labs. ** Space for rent ** | %|__________________________________________________________________________| %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
mem@zinn.MV.COM (Mark E. Mallett) (10/26/88)
In article <171@libove.UUCP> root@libove.UUCP (Jay M. Libove) writes: > > While I am using it manually, if a cron job comes up that calls > /usr/lib/uucp/uucico, the LCK.. file in /usr/spool/uucp/ will be ignored > and I will get the modem commands being fired out on the line while I > am connected over it! As yet, this has beena nuisance, but I suppose it > stands to be damaging eventually. Perhaps I am speaking out of turn here, because this is the xenix group and I am speaking of the same problem in the Microport uucico, but this looks like the same problem. When I installed HDB uucp on my Microport Sys V/AT system, I was careful (in the face of having NO documentation, of course) to investigate the format of the new LCK files and change my local comm programs accordingly. Under the HDB convention, each lock file contains the decimal-ASCII number of their owner process - a 10-digit field followed by a newline. I found that even when my comm programs were constructing LCK files with this convention, they were being ignored. A probable reason did occur to me. uucico is likely checking to see if the lock's owner process exists. It is doing this by sending a zero (0) signal (i.e., kill) to that process; a successful return from kill() means that the process does indeed exist. The problem is that an error return from kill() does not necessarily mean that the process does not exist. It can often mean that the process performing the kill() does not have permission to send the signal to the process owning the lock. As proof of this, I tried running my comm programs under ownership of uucp, and the LCK file that they created were indeed honored by uucico, which was also running as uucp. This is not a very good situation. If this is indeed the answer, I suggest that SCO (and Microport) fix uucico to be more intelligent in interpreting the result from the kill() of the LCK owner process. -mm- -- Mark E. Mallett Zinn Computer Co/ PO Box 4188/ Manchester NH/ 03103 Bus. Phone: 603 645 5069 Home: 603 424 8129 uucp: mem@zinn.MV.COM ( ...{decvax|elrond|harvard}!zinn!mem ) BIX: mmallett