fetchmail-friends
[Top] [All Lists]

Re: [fetchmail] SOLVED: problem with pre-connect (fetchmail 6.2.5)

2003-11-04 01:43:46


In the message dated: Mon, 20 Oct 2003 13:07:02 PDT,
The pithy ruminations from fetchmail(_at_)merctech(_dot_)com on 
<[fetchmail] problem with pre-connect (fetchmail 6.2.5)> were:

Some time ago, I described a problem I was having. [Short answer: don't use 
stty. See below for details.]

=> I'm having a problem with the pre-connection command under fetchmail 6.2.5 
(and 
=> I observered the same problem under 6.2.2).
=> 

        [SNIP!]

=> 
=> I've got a script that connects to the router and indicates the status of 
the 
=> WAN connection. It returns the text "online" or "offline" and sets its exit 
=> value to either "0" or "1". The script consistently takes at least 3.5 
seconds 
=> to execute (a human-noticible interval).
=> 
=> I have created a shell script that does the following:
=>      netopia status 1> /dev/null && exec ssh -f -L 9110:pop.myisp.com:110 
shell.myisp.com sleep 
=> 45 < /dev/null > /dev/null
=> 
=> 
=> I expect the netopia command to return 1, causing the fetchmail preconnect
=> command to fail if the WAN connection is down. If the WAN link is up, the ssh
=> tunnel should be set up, and then control should pass back from the
=> preconnection script to the fetchmail process and mail should be retrieved.
=> 
=> When I use that shell script as the preconnect command, it consistently 
fails 
=> with the error message:
=>      pre-connection command failed with status 256
=> regardless of the WAN status.
=> 
=> However, if I manually run the script before and after a failed fetchmail 
poll, 
=> I can see (via sh -x) that both the check of the WAN status and the ssh 
tunnel 
=> setup work correctly, and that the script exits with a return code of 0 if 
the 
=> WAN link is up.
=> 
=> Furthermore, the logs generated by fetchmail show the pre-connection command 
=> failing within one second of the fetchmail process being awakened (the "poll 
=> started" and "command failed" messages have the same timestamp). It appears 
=> as if the check of the WAN status is not being run at all. I've tried 
=> specifying the preconnect command within my .fetchmailrc as both:
=> 

        [SNIP!]

This was part of what pointed to the solution... The "netopia" script, 
actually an expect script, that connects to the router to check the status, was 
failing before getting to any of the time-consuming steps.

The cause of the failure was an "stty" statement... Apparently, when run via 
fetchmail, there's no controlling tty associated, so the stty was failing, 
causing the expect script to exit immediately.

Mark


=> 
=> ------
=> Mark Bergman    Biker, IATSE #1 Stagehand, Rock Climber, Unix mechanic
=> '94 Yamaha GTS1000A^2
=> bergman(_at_)panix(_dot_)com
=> 
=> 
http://pgpkeys.mit.edu:11371/pks/lookup?op=get&search=bergman(_at_)panix(_dot_)com
=> 
=> I want a newsgroup with a infinite S/N ratio! Now taking CFV on:
=> rec.motorcycles.stagehands.pet-bird-owners.pinballers.unix-supporters
=> 15+ So Far--Want to join? Check out: http://www.panix.com/~bergman




<Prev in Thread] Current Thread [Next in Thread>
  • Re: [fetchmail] SOLVED: problem with pre-connect (fetchmail 6.2.5), fetchmail <=