|
|
|
This item is for system problems. If something on Grex isn't working right (line noise on a modem, weird behavior from a program, etc.), this is the place to announce it. Except for security holes. If you find a hole in system security, mail information about it to "staff".
248 responses total.
fag.
You say that like it's a bad thing.
(finally. someone gets it.)
The instructions for using fall bbs scrolled by without me hitting the space bar. Might be hard for beginners to read them. Is this normal?
Define 'normal'.
You know... will her friends shun her and strangers giver her dirty looks for it, or is she still an ordinary, productive member of society?
:)
How can you be a productive member of society without a scrollback buffer?
flash memory?
Ahh, the subtle secrets of life revealed. Thanks, Joe! (resp:8)
A quick question: Exactly what extra output is provided by the -d (debug) option of the bbs command, and is it sent to stdout or stderr? Perhaps it can fulfill a role that I am thinking of requesting a modification for.
I don't know that this is necessarily a problem, but I was rather startled this evening when logging into Grex (using backtalk), and discovering that the default light yellow had been replaced by a light green. Has Jan installed a new version of backtalk? (it's an interesting change. I don't have an opinion as to whether it's good or bad)
It's an accident, I think. I thought I had fixed that when I installed the new backtalk, but it doesn't seem to be fixed. Not sure what happened. Need to go back and re-yellow it.
OK, should be yellow again.
I liked the green better.
When I finish debugging the next release you can have it better - user definable colors.
Apparently, the -d option sends nothing to stderr.
Could an option be added to Picospan, off by default but that can
be turned on, that would send out to stderr (not stdout) something like:
("%s %d %d\n", confname, item, response) ?
You could set your isep/rsep values to begin with some virtually- guaranteed-not-to-occur-normally string to make them easy to pick out and pipe virtually everything through a script which would kick out the line to stderr whenever one was encountered. I thought we didn't have a modifiable copy of picospan here on Grex, so requests to add even something as quick and easy as that might go unfulfilled.
What Mike said is what I do. I wouldn't hold your breath waiting for Picospan to change, Drew. What is it you want to do?
Most times I read bbs by logging in and routing all output to a file via
bbs <bbsin.fil >newresp.grx
then either sz or ftp the file to my machine, depending on how I'm connected.
Of late, some of these reads have been taking a while, and it would be nice
to have a running report of the progress so there's something else besides
inert screen. And since stdout is being routed to the file, it stands to
reason that the progress data should goto stderr.
(Teeing the output of course is not practical - would increase the run time
too much.)
Lynx does not seem to be working, either to my ISP or to UMICH.edu.
Drew - why don't you write a little C program to propcees the output from bbs, write it out to stdout, and write a message to stderr now and then to report progress. You could do it with AWK, too, but C might run faster. Then your command would be something like: /----------------------------------------\ | bbs <bbsin.fil | myfilter >newresp.grx | \----------------------------------------/
What's a startfile? > lynx www.cyberspace.org Alert!: Unable to connect to remote host. Looking up www.cyberspace.org first Looking up 216.93.104.35 Making HTTP connection to 216.93.104.35 Alert!: Unable to connect to remote host. lynx: Can't access startfile http://www.cyberspace.org/
Lynx has been flaky again since last night. Sometimes it cannot access the 'startfile' (the name of the file that you type in when you start lynx) and sometimes it can do so, but then it will not access any links to that page. I have managed to go into lynx and, when it is misbehaving less, type g (go to) and then the URL, and it goes to that site but then not any links to it. I got a message at one point (when it would not even do that) that there were server problems. So I guess grex will just have to be patient. Try mnet. From Ann Arbor dial 661-1234 (?), for login type mnet, password Enter, then next time it wants login type newuser and fill in the form and pick a password. Mnet has a very fast running lynx.
Sounds like maybe the proxy is acting up again.
Web stuff should be working now - dang sent some emails about his problem fixes for the proxy server.
It works just fine today. Grex is also lots lots faster than all week.
There seems to be a problem with the telnet queue, so I've sent a message to staff. SSH can't get a pseudo-tty, and there were (last I checked) 34 remote users and 15 waiting in the queue.
I was just going to ask about that. The queue went down awful fast, too; over a minute or so: Waiting for a free port (? for help) ...23 ...21 ...20 ...19 ...18 ...15 ...10 ...9 ...6 ...1
I noticed the same behavior a few days ago -- can't log in with SSH, and a big queue that goes down to nothing very fast. Not many people were logged in, so there shouldn't have been a queue at all. Tried again a few hours later and the problem had gone away.
Same here.
Joe, John, if you don't know of it, you may find
fixwait -L
interesting. It shows that the queue may still be there even though it
gets processed pretty quickly.
It really is what (I presume) they were thinking, not just a high
wait queue ... look at the 'fixwait -l' output below:
start curr gen dev pid ty host
Oct 3 17:43 Oct 3 17:43 55806 p4 23871 s 130.126.120.23
[snip]
Oct 4 09:13 Oct 4 09:13 59644 pa 19315 s 66.134.113.250
Oct 4 06:01 Oct 4 06:01 59166 u6 26180 t 66.200.123.82
Oct 4 08:59 Oct 4 08:59 59566 r7 17118 t 66.30.44.42
Oct 4 08:59 Oct 4 08:59 59570 uf 17150 t 66.30.44.42
Oct 4 08:59 Oct 4 09:00 59575 tb 17153 t 66.30.44.42
Oct 4 08:59 Oct 4 09:00 59577 rc 17168 t 66.30.44.42
Oct 4 08:59 Oct 4 09:00 59581 u7 17178 t 66.30.44.42
Oct 4 09:00 Oct 4 09:00 59583 r4 17286 t 66.30.44.42
Oct 4 09:00 Oct 4 09:00 59585 rb 17363 t 66.30.44.42
Oct 4 09:00 Oct 4 09:00 59587 t8 17392 t 66.30.44.42
Oct 4 09:00 Oct 4 09:00 59588 ta 17394 t 66.30.44.42
Oct 4 09:01 Oct 4 09:01 59590 r2 17542 t 66.30.44.42
Oct 4 09:01 Oct 4 09:01 59592 u9 17602 t 66.30.44.42
Oct 4 09:02 Oct 4 09:02 59594 q6 17674 t 66.30.44.42
Oct 4 09:02 Oct 4 09:03 59598 sa 17796 t 66.30.44.42
Oct 4 09:03 Oct 4 09:03 59599 sd 17831 t 66.30.44.42
Oct 4 09:04 Oct 4 09:04 59608 sf 18203 t 66.30.44.42
Oct 4 09:06 Oct 4 09:06 59617 q1 18473 t 66.30.44.42
Oct 4 09:06 Oct 4 09:06 59618 q5 18479 t 66.30.44.42
Oct 4 09:07 Oct 4 09:07 59619 sb 18511 t 66.30.44.42
Oct 4 09:13 Oct 4 09:13 59647 rd 19407 t 66.30.44.42
Oct 4 09:14 Oct 4 09:14 59651 r0 19503 t 66.30.44.42
Oct 4 09:14 Oct 4 09:14 59652 t4 19541 t 66.30.44.42
Oct 4 08:40 Oct 4 08:40 59514 p9 14056 s 80.237.48.22
Oct 4 08:38 Oct 4 08:38 59507 q3 13730 t 80.25.120.149
1 waiting, 72 remote + 1 local users; 72 max remote users; 19600 head
Fixwait is still confused. $ fixwait -L 0 waiting, 47 remote + 0 local users; 72 max remote users $ who -q <snip long line> # users=42 $ fixwait -L 0 waiting, 47 remote + 0 local users; 72 max remote users $
something ain't working. when i ssh/telnet in and enter my pass, the connection closes. it's 4pm here, but i been waiting for you to get out of bed. i need my mail, man. don't make me stop donating my 0$ per month. i don't mean to make threats but i AM flying to chicagoland tomorrow and i will find you and make your ass like a japanese flag.
oh ya it's grexwalk day. i'll go smoke a joint then, goverdomme.
" Logins are currently denied by /etc/nologin: Connection to cyberspace.org closed. "
Grex was down due to power problems. I just now removed the login block.
Re #35: Yeah. Look us up when you're in Chicago.
| Last 40 Responses and Response Form. |
|
|
|
- Backtalk version 1.3.30 - Copyright 1996-2006, Jan Wolter and Steve Weiss