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