Subj : Apache 1.3.22 up but?
To : All
From : Mike Luther
Date : Tue Oct 30 2001 02:20 am
Well, Apache 1.3.22 is up and running for test purposes at the already known
208.180.150.64 address for 1:117/3001 here as well as on some other boxen for
research ..
I stuck my, not-designed-to-ever-encourgage-web-traffic page mirrored on it for
test purposes here on site. The idea being that it is still going to be far
cheaper to eventually use the fixed IP address I'm stabilizing, or trying to,
instead of pay my IP to host dis and dat.
Well maybe ..
Instantly .. about a quarter of a meg a day even on this DHCP address of logs
similar to:
Of course all the 208.180.###.### are coming from my COX IP's dominion! But
gee, maybe I ought to let them suffer instead of asking IJFIRE to dump dis and
dat and having to constantly re-write the dump matrix stuff?
I see where Mikey has more to learn.
On a more practical note, Apache has one other disturbing error I've seen for
the first time. I get very few trap errors on this old 1542C Adaptec SCSI box!
Yes, it is tape backed, even so that it only hosts all the BBS and TELNET and
FTP server stuff ... but ..
Apache has this nice need to perform a graceful shutdown rather than just
whatever. And there are short kill scripts to help both do that as well as
perform a graceful re-start.
But remember! This is the box I've had some of these curious hard locks with
no trap errors which .. now more conclusively point to the CANARY portion of
NORMAN 4.73 that is looking at the SYSTEM stuff on scan going into DOS-VDM
sessions via the OS/2 .CMD file which runs things..
One of them taught me a new lesson about APACHE 1.3.22 yesterday. If you abend
the box and bring it up hard through CHKDSK, APACHE throws repeated SYS3175
after SYS3175 forever with the Desktop nearly locked if the TCP/IP interface is
not up and running as the aut-load for the desktop attempts to rebuild the
desktop from the crash. I quote:
I discovered that with a great deal of fanfare, I can intercept the building
Desktop inbetween END, END, END, runs of the trap error message. One by one I
can get all the BBS tasks and so on killed. Then inbetween the brief flashes
of another SYS3175 error just like the above, I can open the APACHE folder, and
then with work, slam in the KILL script which will properly terminate this
beast!
That is not good.
Fine. I can go to use the RESTARTOBJECTSONLY game? Or maybe go to the method
of restarting the entire Desktop and the WPS out of STARTUP folder? But I sure
can't go to an auto-restart deal on a trap deal, can I? The box would forever
get trapped in round after round of this!
Knowing this now, early in the burn, How do I maintain the mission critical
and especially REMOTE RESET capability of a box like this under this scenario?
Any thought about using the KILL script as part of the .CMD file to fire off
this beast on a STARTUP.CMD approach, then firing it off as a second step in
that game?
Equally important from an OS2INET standpoint, just what methodology does one
use with our available OS/2 tools for net connectivity to keep a joint BBS and
INET server presence up mission critical style?
Inquiring mind wants to know.
--> Sleep well; OS/2's still awake! ;)
Mike @ 1:117/3001
--- Maximus/2 3.01
* Origin: Ziplog Public Port (1:117/3001)
