kvancamp@ARDEC.arpa (Kenneth Van Camp -FSAC-) (12/29/86)
I have just recently established a UUCP connection between two of our Unix systems, and am having a few problems I was hoping someone could help with: My system admin's documentation on installing UUCP gives the following hint for debugging connections by first using the -r option on the UUCP command to force the request to be queued, instead of trying to execute immediately, then invoking Uucico as: /usr/lib/uucp/uucico -r1 -x4 -ssystem This works very nicely the first time I try it, and it has helped immeasureably in troubleshooting my send/expect pairs in the L.sys file. Unfortunately, this command only works once; the second time I get the error message: RETRY TIME (3300) NOT REACHED which I can only get rid of by rebooting the system (or so it seems). I was under the impression that using the notation 'Any' (minus the quotes, of course) for the time in the L.sys entry would allow me to retry a UUCP command any time I like. I also tried 'Any,1' to force the minimum retry time to be one minute, with the same results. I think a lot of my confusion could be solved if I had a man page entry on Uucico. I work on three different Unix systems, and none of them has one. I understand that the -x4 flag above sets the debugging level, but does anyone know what the -r1 does? And is there another flag that will take care of my retry time error? Finally, since 'Any,1' sets the minimum retry time for UUCP, is there any way to set a MAXIMUM retry time? That is, how can I force UUCP to try again every five minutes (say) until the queue is empty? My transfers have been occurring, but they have been taking horribly long to occur and often do not seem to be retried until I reboot. I appreciate any help or advice. Thanks. --Ken Van Camp <kvancamp@ARDEC.ARPA>
campbell@maynard.BSW.COM (Larry Campbell) (12/30/86)
In article <2051@brl-adm.ARPA> kvancamp@ARDEC.arpa (Kenneth Van Camp -FSAC-) writes: ... > /usr/lib/uucp/uucico -r1 -x4 -ssystem >This works very nicely the first time I try it, and it has helped >immeasureably in troubleshooting my send/expect pairs in the L.sys file. >Unfortunately, this command only works once; the second time I get the error >message: > RETRY TIME (3300) NOT REACHED >which I can only get rid of by rebooting the system (or so it seems). rm the file "/usr/spool/uucp/STST.systemname", which contains the date and time of the last attempted call to "systemname". >... does anyone know what the -r1 does? The -r1 flag sets your "role" to "master". In a UUCP connection, there is a "master" who initiates the call, and the "slave", who doesn't. -- Larry Campbell The Boston Software Works, Inc. Internet: campbell@maynard.bsw.com 120 Fulton Street, Boston MA 02109 uucp: {alliant,wjh12}!maynard!campbell +1 617 367 6846 ARPA: campbell%maynard.uucp@harvisr.harvard.edu MCI: LCAMPBELL
jrw@hropus.UUCP (Jim Webb) (12/30/86)
> My system admin's documentation on installing UUCP gives the following > hint for debugging connections by first using the -r option on the UUCP > command to force the request to be queued, instead of trying to execute > immediately, then invoking Uucico as: > /usr/lib/uucp/uucico -r1 -x4 -ssystem > This works very nicely the first time I try it, and it has helped > immeasureably in troubleshooting my send/expect pairs in the L.sys file. > Unfortunately, this command only works once; the second time I get the error > message: > RETRY TIME (3300) NOT REACHED > which I can only get rid of by rebooting the system (or so it seems). The retry time for uucp is stored in the status file for the machine. In, how should I put this, ok, pre-HoneyDanBer uucp, the status file is "usually" /usr/spool/uucp/STST.<system> while HDB puts it in /usr/spool/uucp/.Status/<system> where <system> is (obviously) the name of the machine. To rid yourself of the RETRY TIME NOT REACHED problem, just remove the above file and redo the uucico. > I was under the impression that using the notation 'Any' (minus the > quotes, of course) for the time in the L.sys entry would allow me to retry a > UUCP command any time I like. I also tried 'Any,1' to force the minimum > retry time to be one minute, with the same results. The Any means that you can call the machine at any time. It is used so that if you want to call a machine only during certain hours, you can easily do so. For example, suppose you just want to call Hawaii only after hours to save money on phone bills, you would set this field appropriately. > I think a lot of my confusion could be solved if I had a man page > entry on Uucico. I work on three different Unix systems, and none of them > has one. I understand that the -x4 flag above sets the debugging level, > but does anyone know what the -r1 does? -r1 means put you in the master role, meaning to control the call. If you do not use this flag, uucico assumes that it is receiving the call, not originating it, akin to it being called from login. > And is there another flag that > will take care of my retry time error? Nope. > > Finally, since 'Any,1' sets the minimum retry time for UUCP, is > there any way to set a MAXIMUM retry time? That is, how can I force UUCP > to try again every five minutes (say) until the queue is empty? My > transfers have been occurring, but they have been taking horribly long > to occur and often do not seem to be retried until I reboot. The only way uucp is going to look for work is if it is asked by either running a uucico to that machine, or in HDB, by running uusched. If you are having problems with a specific machine, how about putting an entry in cron to try to call the machine if there is work queued for it. I suppose that it would be something like: if [ `uustat -s <system>` ] then rm "the status file" /usr/lib/uucp/uucico -r1 -s<system> fi Granted, if you are currently talking with <system> when you run this, you waste some time, but the lock files will (should) prevent ill happenings. You could get robust and look into the actual lock files and not call if you are talking. I suppose you could look in the status files as well, but their info is not as reliable. You should put entries in cron to call uucico or uusched every so often anyway. I __THINK__ that in pre-HDB uucp if you call uucico without a system (eg uucico -r1) it will do the searching for work, but it has been a while since I used the older uucp. Have fun!!! -- Jim Webb "Out of phase--get help" ...!ihnp4!hropus!jrw "Make sure comments and code agree. If not, write a man page..."
snafu@ihlpm.UUCP (Wallis) (12/31/86)
The 'retry time' mechanism is used by basic
networking when a uucp attempt to another machine
has failed. This prevents a bad connection from
eating up too many resources by limiting how often
the machine can be called. The mechanism can be
overridden using the `Uutry` command, which
basically invokes uucico in master mode, redirects its
output to the file /tmp/<system>, and then does a tail -f
on /tmp/<system>. This allows you to monitor the
session and break out of the tail if you wish
before uucico is complete. The command
'/usr/lib/uucp/Uutry -r <system>', when run from
root, will override the retry time. Hope this
helps you.
--
Dave Wallis
ihnp4!ihlpm!snafu
AT&T Network Systems, Inc.
(312) 510-6238rick@seismo.CSS.GOV (Rick Adams) (12/31/86)
> > And is there another flag that > > will take care of my retry time error? > Nope. The 4.3BSD uucp will ignore the retry time if debugging is on. So, technically, you could override the retry time by using the -x flag. ---rick
hakanson@orstcs.UUCP (hakanson) (01/01/87)
/* Written 12:03 pm Dec 29, 1986 by kvancamp@ARDEC.a@brl-adm in comp.unix.ques */ /* ---------- "Help with UUCP" ---------- */ > . . . > RETRY TIME (3300) NOT REACHED > . . . > I also tried 'Any,1' to force the minimum > retry time to be one minute, with the same results. /* End of text from orstcs:comp.unix.ques */ From looking at the sources in 4.2bsd (and 4.3bsd, I presume), I found that the minimum retry time is 5 minutes, even if you set it smaller. I think the default was about 60 minutes, but I may have misremembered. At any rate, this will probably be different on non-BSD uucp's.... Marion Hakanson CSnet: hakanson%oregon-state@csnet-relay UUCP : {hp-pcd,tektronix}!orstcs!hakanson
jim@otto.UUCP (Jim Thompson) (01/06/87)
Summary: Expires: Sender: Followup-To: Distribution: Keywords: In article <217000001@orstcs.UUCP> hakanson@orstcs.UUCP (hakanson) writes: > >/* Written 12:03 pm Dec 29, 1986 by kvancamp@ARDEC.a@brl-adm in comp.unix.ques */ >/* ---------- "Help with UUCP" ---------- */ >> . . . >> RETRY TIME (3300) NOT REACHED >> . . . >> I also tried 'Any,1' to force the minimum >> retry time to be one minute, with the same results. >/* End of text from orstcs:comp.unix.ques */ > >From looking at the sources in 4.2bsd (and 4.3bsd, I presume), I found >that the minimum retry time is 5 minutes, even if you set it smaller. >I think the default was about 60 minutes, but I may have misremembered. >At any rate, this will probably be different on non-BSD uucp's.... > (Opps.) Well, under 4.2 bsd and Sun3.0 Setting Any,1 or even Any,0 will work as expected. The DEFAULT retry time is 5 min. Read the source a little closer. The original poster had a problem whilst invoking uucico -r1 -s(system) without first removing the /usr/spool/STST.system. (In other dirs in HDB and 4.3) There (usually) exists some kind of executable or script called 'uupoll' in /usr/lib/uucp. Here's one: (written from scratch, so don't flame on minor mistakes) #! /bin/sh cd /usr/lib/uucp rm -f /usr/spool/uucp/STST.$1 exec uucico -r1 -s$1 $2 Note that the 'rm' line may have to be changed if you keep your 'status' files somewhere other than /usr/spool/uucp. Invoke as 'uupoll system-name' or (optionally) (if you are debugging) uupoll system-name -x5 (or 7 or 9) -- --Jim ____________________________________________________________________________ | try: {akgua,ihnp4,mirror,sdcrdcf}!otto!jim Jim Thompson | | for "smart" mailers -- jim@otto.UUCP Las Vegas Sun | | 2551 Green Valley Pkwy | | <My company doesn't care what I think..> Henderson, Nv. 89015 | | "All of life is a blur of Republicans and meat" (702) 454-4636 | ----------------------------------------------------------------------------
hakanson@orstcs.UUCP (hakanson) (01/09/87)
Oh boy, a controversy! Well, a disagreement, anyway. >/* Written 4:16 pm Jan 5, 1987 by jim@otto in orstcs:comp.unix.ques */ >In article <217000001@orstcs.UUCP> hakanson@orstcs.UUCP (hakanson) writes: >. . . >> >>From looking at the sources in 4.2bsd (and 4.3bsd, I presume), I found >>that the minimum retry time is 5 minutes, even if you set it smaller. >>I think the default was about 60 minutes, but I may have misremembered. >>At any rate, this will probably be different on non-BSD uucp's.... >> >(Opps.) > >Well, under 4.2 bsd and Sun3.0 Setting Any,1 or even Any,0 >will work as expected. The DEFAULT retry time is 5 min. >Read the source a little closer. >. . . >/* End of text from orstcs:comp.unix.ques */ Well, I did read the source a little closer, and it turns out I was right in the first place (at least, with respect to the fairly vanilla 4.2bsd source on our VAX (now running 4.3bsd)). From conn.c: /* global variable Retrytime is set here */ if ((p = index(s, ',')) == NULL) { Retrytime = RETRYTIME; } else { i = sscanf(p+1, "%d", &rtime); if (i < 1 || rtime < 5) rtime = 5; Retrytime = rtime * 60; } The DEFAULT is RETRYTIME (55 minutes). If the value given after the "," is invalid or if it is less than 5, then 5 will be used. Note that the code for 4.3bsd is almost identical, except that the check for "rtime < 5" is changed to "rtime < 0", and this change may have made it into later releases of 4.2bsd (so it seems likely that we are both right). Interestingly, it behaves differently if there is no "," than if there is a "," with nothing following it (";" for 4.3bsd) -- I suppose this might be considered a feature by some. Well, at least the memory (mine) hasn't flaked out this time.... Marion Hakanson CSnet: hakanson%oregon-state@csnet-relay UUCP : {hp-pcd,tektronix}!orstcs!hakanson
dennis@rlgvax.UUCP (Dennis Bednar) (01/15/87)
In article <2051@brl-adm.ARPA>, kvancamp@ARDEC.arpa (Kenneth Van Camp -FSAC-) writes: > RETRY TIME (3300) NOT REACHED Try removing the STST.machine file, in /usr/spool/uucp. If you don't, a soon attempt to run uucico will fail. > but does anyone know what the -r1 does? The -r1 sets the mode to "master" or "caller", as opposed to "slave" or "server". The "role" variable inside uucico is by default 0 (slave), and -r1 causes the variable to be set to 1 (master). > to try again every five minutes (say) until the queue is empty? My > transfers have been occurring, but they have been taking horribly long > to occur and often do not seem to be retried until I reboot. Also try putting an entry in the crontab file to run uucico periodically. If uucico exhausts the queue, and you queue up new information, the new uucico started will not be able to file transfer because of the short time (the 3300 you mentioned). Unless you type in another uucp or mail or postnews command, there is nothing to "poke" uucico to tell it to start file transfering again. This is because uucico is *not* a daemon, but rather, a one-shot program. -dennis -- -Dennis Bednar {decvax,ihnp4,harpo,allegra}!seismo!rlgvax!dennis UUCP
dennis@rlgvax.UUCP (Dennis Bednar) (01/15/87)
In article <856@ihlpm.UUCP>, snafu@ihlpm.UUCP (Wallis) writes: > overridden using the `Uutry` command, which > basically invokes uucico in master mode, redirects its > output to the file /tmp/<system>, and then does a tail -f > on /tmp/<system>. This Some machines don't have the Uutry sh script. I've only seen it on a 3b2 which I think was running the HoneyDanber version of uucp. -- -Dennis Bednar {decvax,ihnp4,harpo,allegra}!seismo!rlgvax!dennis UUCP