|
|
| Author |
Message |
| 25 new of 364 responses total. |
davel
|
|
response 275 of 364:
| 
Aug 14 10:34 UTC 1997 |
Re 271,273: it connected, paused a few moments, displayed the "Grex central"
lines & the "New to grex?" line, maybe paused a moment or two, displayed
"(ttyr0) grex ", definitely paused but for maybe a second or two *not*
minutes, displayed the "login:" prompt. Then immediately or almost so it gave
the connection-closed message - no time for me to respond to the login prompt.
This happened repeatedly, exactly the same. I gave up, disconnected from
where I was already logged in (izzy5@isthmus.net) & dialed in. There were
a whole lot of folks on over the net at that point.
|
bmoran
|
|
response 276 of 364:
|
Aug 14 12:57 UTC 1997 |
We're back to 'slower than mud' this morning. !w says it's in the 20's all
around. Ah.. just like in the old days!
|
mdw
|
|
response 277 of 364:
|
Aug 14 23:38 UTC 1997 |
Response 271 included enough details that I was able to find the log
records associated with that session. So far as telnetd is concerned,
it was a very short, but "normal" session. It was able to allocate a
pty, fork, & execute login. It was then able to read the "login:"
prompt, which means that login had, in fact, started running.
Immediately after that, it got an EIO error upon reading the pty. This
can (supposedly) only happen when the slave side gets closed, and in
fact normally happens when the user terminates his login shell. It also
occasionally happens before the slave side starts up, but in that case,
telnetd has logic to retry up to 10 times, and in fact, it rarely has to
retry more than once, and never more than twice. In this case however,
since telnetd had seen the "login:" prompt, it checked, found the child
still existed, and sent it a "TCSIG SIGHUP". This did, in fact, kill
the child, and so telnetd was done.
The most likely explanation that I can come up with is that there was
something about tty settings passed in from the telnet client, that
caused login to exit fast. Perhaps it was told to switch into "cbreak"
mode with a non-zero VTIME value. Perhaps something else happened.
Thanks for the report, in any case, if nothing else, it at least
suggests some possible avenues for investigation.
|
valerie
|
|
response 278 of 364:
|
Aug 15 06:20 UTC 1997 |
This response has been erased.
|
davel
|
|
response 279 of 364:
|
Aug 15 10:48 UTC 1997 |
(Obviously I was asleep. It was izzy5.izzy.net, not what I said. It happened
the same way this morning - except for a "#" before the "login:". So I
telnetted from there to izzy4, logging in in essentially the same way, & here
I am. Seems pretty clear that it's something about that one machine, in some
bizarre fashion.)
Marcus, thanks for following up.
|
richard
|
|
response 280 of 364:
|
Aug 15 16:48 UTC 1997 |
hmmm...Ijust tried to go to the Poetryconf and got:
mkimap trouble--too many items 999 at msgno 1007
Does picospan not allow conf sto have more than 1,000items?
Anyway it is not allowing accessto the conf...
|
toking
|
|
response 281 of 364:
|
Aug 15 17:03 UTC 1997 |
it is through backtalk....and there are <I think> 1007 items
|
toking
|
|
response 282 of 364:
|
Aug 15 17:16 UTC 1997 |
yep 1007...and i have it set up as my starting confrence, i get a prompt
that says:
<no conf>:
When I telnet in that is.
|
richard
|
|
response 283 of 364:
|
Aug 15 17:46 UTC 1997 |
so poetry is grex's first backtalk-only conf now I spose...interesting
|
toking
|
|
response 284 of 364:
|
Aug 15 19:14 UTC 1997 |
from the looks of it...but thats a bad thing
|
senna
|
|
response 285 of 364:
|
Aug 16 18:09 UTC 1997 |
Until jenna restarts it, yes.
|
toking
|
|
response 286 of 364:
|
Aug 16 20:03 UTC 1997 |
ok...how do you restart a confrence that you cannot access?
|
scott
|
|
response 287 of 364:
|
Aug 16 22:43 UTC 1997 |
Cfadm does it, without needing to use PicoSpan. I'd suggest starting the new
conference, then using Backtalk to link the last few items over, then deleting
those items in the old conference so that it can be read by PicoSpan.
|
richard
|
|
response 288 of 364:
|
Aug 16 23:55 UTC 1997 |
why wont picospan read a conf with over 1,000 items? not like grex
doesnt have the diskspace for a conf that large?
|
richard
|
|
response 289 of 364:
|
Aug 17 00:02 UTC 1997 |
Actually, PIcospan should be modified to allow fw's to restart their own
confs..since fw's can do so anyway by killing out all the items one by
one, I dont see the rationale for not giving them the extra
"restart"command. This would surely save cfadmin a lot of work right?
|
scg
|
|
response 290 of 364:
|
Aug 17 03:12 UTC 1997 |
When cfadm restarts a conference, they don't just enter a restart command in
Picospan. They create a new conference (a process mostly done outside of
Picospan, I think), and then change conference names around so that the name
of the conference points at the new conference. A simple PicoSpan command
that restarts a conference would require significant added functionality
beyond what PicoSpan supports now.
|
kaplan
|
|
response 291 of 364:
|
Aug 17 12:58 UTC 1997 |
Backtalk is very hard to use right now because the buttons are all coming up
as broken pictures. Text alternatives are not showing up so I had to try to
remember button function based on position.
|
srw
|
|
response 292 of 364:
|
Aug 17 17:02 UTC 1997 |
I entered a response in the announcements item about HVCN. HVCN was off the
internet for 22+ hours starting at 11:15 AM yesterday. The line we share with
the city and county was out of commission. I don't have any details about
that. The City and County websites were also offline during that period.
This was a problem for Grex because Grex stores all of its graphics on that
server. As a result, none of the Graphics on our web pages, including
all of the backtalk buttons, were operative during that time.
HVCN is back now, and everything is working fine.
|
richard
|
|
response 293 of 364:
|
Aug 17 18:50 UTC 1997 |
somebody stillneeds to delete a fdw items from
what is now "oldpoetry" so it can be accessed...no point keeping
it around if it cantbe accessed.
I still dont understand the 1,000 items max bit...was that
some arbirtrary number Maarcus put in the code?
|
scott
|
|
response 294 of 364:
|
Aug 17 22:20 UTC 1997 |
At the time I'm sure it seemed to be al extreme that nobody would ever reach.
Performance would suffer greatlt with that many items.
|
scg
|
|
response 295 of 364:
|
Aug 17 22:58 UTC 1997 |
Every computer program has limits of some sort on how much if what it does
it can do. In writing a program, generally you try to set such limits much
higher than you think will ever be reached, but limits do need to be set
somehwere. I'm guessing Marcus didn't think conferences would ever come
anywhere close to 1,000 items.
|
toking
|
|
response 296 of 364:
|
Aug 17 23:00 UTC 1997 |
I sent a message to arianna about this, but we still cant link then delete
those last 8 items, unless pistachio has FW options, which I asked her to
check <all I can ghet to until tomorrow is vanilla> any suggestions?
|
drew
|
|
response 297 of 364:
|
Aug 18 00:47 UTC 1997 |
Why 1000? Why not 1024, or more approriately, 32767 or 65535?
|
scg
|
|
response 298 of 364:
|
Aug 18 03:37 UTC 1997 |
Not really a system problem we can do anything about, but MCI is having
horrendus packet loss between the Ameritech NAP and what appears to be MCI's
more than 50% packet loss getting to Grex, and I can type a line of text, go
off and get a drink, and it still won't be finished echoing. This has been
going on since mid-afternoon sometime.
|
mcnally
|
|
response 299 of 364:
|
Aug 18 04:34 UTC 1997 |
As far as the Backtalk problems with the graphics when HVCN is not
available, such problems can be substantially lessened by using the
HTML "ALT" tag to assign alternate text labels to the in-line images --
this is also a help to non-graphical browsers and those of us who are
sometimes impatient enough to turn off automatic image-loading while
browsing.
*MOST* of the images seem to do this (at least on the pistachio page
I was looking at..) but not all of them (example: the Grex logo at
the top of the page [grexweb2.gif] )
|
