lynx-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

lynx-dev 2.8.1 fails under cron (with ncurses & nsl-fork)


From: Kim DeVaughn
Subject: lynx-dev 2.8.1 fails under cron (with ncurses & nsl-fork)
Date: Tue, 1 Dec 1998 06:00:18 -0800

A few days ago, at my suggestion, one of our sysadmins upgraded lynx
from v2.8-rel.2 to v2.8.1-rel.1, on our FreeBSD 2.2.7-STABLE platforms.

Immediately, some users who were running "lynx -dump" via cron, started
getting failures, using such simple cron'd shell scripts as:

 #!/bin/sh

 /usr/local/bin/lynx -dump http://www.sun.com/ >$HOME/tmp/lynx.out

 exit

Adding -trace to the above invocation, I would see the tail end of the
Lynx.trace file showing:

 >HTParse: aName:http://www.sun.com/   relatedName:
 >1
 >HTParse: result:http://www.sun.com/
 >Could not get ttyname or open UTMP fileLYMain.c: User in REMOTE domain
 >Entering mainloop, startfile=http://www.sun.com/
 >getfile: getting http://www.sun.com/
 >
 >HTParse: aName:http://www.sun.com/   relatedName:
 >HTParse: result:www.sun.com
 >
 >HTParse: aName:http://www.sun.com/   relatedName:
 >HTParse: result:
 >Entered HTAnchor_findAddress
 >New anchor 0x109900 has hash 2 and address `http://www.sun.com/'
 >HTAccess: loading document http://www.sun.com/
 >HTParse: aName:http://www.sun.com/   relatedName:file:
 >HTParse: result:http
 >HTParse: aName:http://www.sun.com/   relatedName:
 >HTParse: result:www.sun.com
 >HTParse: aName:http://www.sun.com/   relatedName:
 >HTParse: result:http
 >HTParse: aName:http://www.sun.com/   relatedName:
 >HTParse: result:www.sun.com
 >Looking up www.sun.com.
 >HTParseInet: parsing `www.sun.com'.
 >HTParseInet: Can't find internet node name `www.sun.com'.
 >Unable to locate remote host www.sun.com.
 >HTTP: Unable to connect to remote host for `http://www.sun.com/' (errno=10).
 >
 >Alert!: Unable to connect to remote host.
 >
 >HTAccess:  status=-29999
 >HTAccess: `http://www.sun.com/' has been accessed, No data loaded.

with the error email from cron saying:

 >From: root (Cron Daemon)
 >To: kimdv
 >Subject: Cron <address@hidden> $HOME/tmp/cron.test
 >X-Cron-Env: <SHELL=/bin/sh>
 >X-Cron-Env: <HOME=/home/kimdv>
 >X-Cron-Env: <PATH=/usr/bin:/bin>
 >X-Cron-Env: <LOGNAME=kimdv>
 >X-Cron-Env: <USER=kimdv>
 >
 >lynx: Can't access startfile http://www.sun.com/

and the contents of the redirected stdout file either 0-length, or contain-
ing the error msg:

 >Exiting via interrupt: 15

The same script would run fine, when executed manually from the cmd line.
Only when it was run under cron, would it fail.


After some investigation, I found that lynx had been ./configure'd with the
--enable-nsl-fork  option turned on, which would cause the failure, but
ONLY when using ncurses (either FreeBSD's 1.8.6/ache, or Tom's 4.2-981121).

Enabling nsl-fork when slang (1.2.2) was used in the build, works just fine.

And, of course, there is no problem with any of the combinations, if a
numerical IP address is used in the URL, instead of the domainname.


I took a look at the ifdef'd NSL_FORK code in HTTCP.c, but since I don't
really know what enabling nsl-fork is *supposed* to do in user observable
terms (the "z" key seems to work for me just fine, without the option having
been enabled), I don't really know what to look for.

I did see SIGTERM's being issued in varios places in the code, and since a
msg about that is what may get written to output file (as above), it could
well be (as one of the other folks here said on an internal newsgroup):

| [snip of explanations]
|
| SWAG:  The difference is due to the way the two libraries set up
|        signal handlers and is getting caught in the cron job because
|        there is no tty associated with the cron'ed lynx which is
|        either exercising a signal handler unexpectely _or_ causing a
|        'surprise' return from a select() somewhere.
|
| Or maybe not ;-(


Anyway, the immediate fix is just to get our sysadmin to recompile, without
enabling the nsl-fork option.

For a proper fix, I'll have to leave it to someone who understands the signal
handling, and the screen-handling libs, alot better than I currently do ...

/kim

reply via email to

[Prev in Thread] Current Thread [Next in Thread]