268 new of 292 responses total.
i don't know if this is connected to Merit or not, however, U of M had a fire (apparently) in the computer area, so they've been trying to deal with this. I can't get into my U of M mail (apparently only a few boxes were destroyed and thus some people can get access and some can't.). That may have a connection to the Merit problem. <shrugs> dunno.
That's probably it.
Yep.. According to reports, a bank of batteries in the Computing Center building caught fire and began leaking acid. Fire crews shut down power to the building and it's taken a while to straighten things out..
That would explain it. I can't get to my email either.
When I came into work this morning at UM North Campus, I was told that some idiot severed a major internet connection with a backhoe in Ohio. The university lost e-mail and internet access for the entire morning because of it. I could only access UM sites from here until noon.
That also happened. (Backhoes: nature's most fearsome predator of the helpless fiber-optic cable..) If you're interested in reading about that one there was an article in today's (9/30) Wired News..
pass
Dpfitzen reports a problem with getting disconnected when trying to send e-mails. Has this happened to anyone else (using Pine)? I suggested that it might be caused by hitting Alt-X (a Procomm command to hang up) instead of Ctl-X, but would like to know if other people are getting disconnected while sending e-mail with Pine.
OK, this is really weird. I tried to send mail just now and found that somehow my .pinerc had changed, with a line added that said default-fcc=nagraj@diversion.com THis caused pine to reject my mail, because I have no save folder called "nagraj@diversion.com". My .pinerc is permitted 644, so no one else should have been able to touch it, and I don't remember ever seeing that address before (and it isn't in my current mail file or any of my saved mail files). I think I'll change my password, though as far as can tell from "last", no one else has logged in as me today. Any idea what happened?
see 21 see 22 Something funky has been happening that "isn't a problem". Additionally, I'm experiencing periodic "seizure", which I can't explain where: everything runs fine, then exverything seems to halt, no text, no echo, no answer to AYT and even pinging grex tends to fail. Seems likely to be two distinct problems, but oops - prolly not "problems"
fwiw [No name] (DIVER-HST) Hostname: DIVERSION.COM Address: 207.126.100.96 System: ? running ? Record last updated on 18-Oct-96. Database last updated on 30-Sep-99 04:34:27 EDT.
ZDNet article on the fiber cut: http://www.zdnet.com/intweek/stories/news/0,4164,2343896,00.html Article posted to mtu.resnet, forwarded from Jeff Ogden, describing in detail the UM fire: http://www.tech.mtu.edu/~dmbrodbe/fire.txt
I just got disconnected while in the Pine index and am now getting occasional
garbage in the middle of blank lines
Help (for more help), pine (fm
i ia
r 4 n
The above is typical.
I got to look at CCB several times -- once just after the fire, when there still a very thick haze of smoke inside (we went in, turned power off on the IFS machines, and got out of there), and again late today, to salvage non-critical hardware like power cables and the like. The smoke was almost entirely gone today when I looked, so I was able to wander around back to the UPS area and look at where the fire started. It took me a bit to find it -- I had never been back there before, and there is a maze of low down concrete rooms which house the boilers and other bits of ventilation system. I knew I had finally found the room, though, when I found one which had a *black* ceiling. There was a lot of broken glass in there, as apparently all the ceiling fixtures had exploded in the heat (wonder where all the mercury went?) The UPS system has a large number of big blue 70's style black boxes, with various sorts of cryptic labels on them. I never did figure out which ones (if any) housed the diesels, but along the back wall, there were a number of big anonymous looking boxes that turned out to be the battery racks. I could tell because the furthest one back was *the* one that burned. The blue paint had turned into white ash, the shiny metal under it was black with corrosion and soot, and of course, the batteries were still inside. The ones in the bottom half of the case didn't look too bad, they were still white plastic cases on shelves. Along the top half, though, the cases were severely melted and carbonized, and had mostly slumped into a thick lumpy glaze on the tops of the batteries. (The shelf probably kept the bottoms from getting so hot). The wiring conduits above these batteries had definitely undergone an unusual experience. These were basically aluminum tubing with really heavy gauge wire rope conductors inside. Presuambly they had once been insulated, but evidently where the insulation had melted, the conductors had touched the tubing, and vaporized it. So the tubing basically had very elongaged and slightly irregular holes chewed along one side of it. There were several other UPS boxes next to the battery case, and while these weren't in nearly as bad a shape as the battery case, they showed distinct signs of damage. These cases happened to have small control panels on them, with some sort of meter (voltage? current?) consisting of a glass faceplate and black plastic framing it. Much of this had melted and deformed in the heat, giving it a very surrealistic apparance. Apparently, the fire put itself out. Lucky us.
i'll bet that the sheer volume of smoke and already oxidized gases choked out the fire by starving it of sufficient oxygen to keep it going. between that and the soot and acid gas, it makes a good argument for keeping these things in a *poorly* ventilated, cool basement room.
Thanks for the description, Marcus.
re #38 Didn't the data center have a form of automated fire protection? I understand that housing such a vast quantity of batteries in one place constitutes a severe fire hazard. ..
Yesterday, repeated efforts to log in connected to the termserver (got the "Welcome to Grex! (it may take a few seconds to connect)" message), followed quickly by a disconnect. An attempt to come in over the net got "connection refused".
I had an interesting error when I was on Grex this morning. I was typing a response somewhere, when suddenly every keystroke just made the computer beep at me. I have _no_ idea if this was the fault of the computer I was on, or of Grex, sinec I had to run anyway and I'm now logging on from a different computer. Who knows...
Probably your own computer, complaining about something. Was it Windows? Had you hit the ALT key by accident?
No, the data center did not have a fire suppression system. Or so I've heard; I've not actually investigated it myself. The new data center does have a sprinkler system.
Actually, what the old building needed was a smoke alarm. I think it did have sprinklers in some places, but not in the UPS bunker. As it happened, the fire *did* announce itself to public safety -- when the temperature and power went out of bounds, and unfortunately after a lot of smoke had been generated and a lot of wiring melted. The nice thing about the old building was that the UPS was in fact in a concrete bunker well separated from the building, and concrete does not burn very well at all. It's too bad it shared the same ventilation system, otherwise, the disaster could have been a lot less annoying. I doubt any standard sort of fire suppression system would have done much good for the UPS. Sprinklers would have just dumped water on the batteries, which probably would have then shorted out that much faster and more violently. A halon suppression system (which is now illegal to install) probably wouldn't have made any difference to the short, but would have interacted in a very interesting but probably much more deadly fashion with the subsequent electrical fire (it probably would have decomposed, releasing much greater amounts of chlorine, flourine, and etc., which would have greatly hampered recovery efforts and probably damaged more equipment.)
Really, until the short condition (assuming that's what it was) was removed, nothing was likely to put out the fire. Were the batteries equipped with fusable links, I wonder?
I've heard of exploding lead-acid batteries in cars, and have thought it was a hydrogen-air explosion, but come to think of it, the plates in the battery are quite close together, and a internal short is quite' possible. That should lead to some fireworks in a fully charged battery. There would be no possible external protection against such a failure, except to not have the explosion of one battery short or disrupt others. I would be interested in what was the initial failure mode, if it can be determined, as I use lead-acid batteries in more than my car.
It seems like a hydrogen/air explosion in any one battery wouldn't produce enough heat for long enough to start a fire, but I could be wrong. The continual smokey smoldering that it sounds like occurred sounds more like an electrical fire to me. We had a maintenance-free lead-acid battery explode on a travel trailer once, and there was no sign of burning or melting damage. (The battery was outside, on the A-frame, next to the propane tanks.)
I had trouble dialing in on 761-3000 tonight; modem connected but I never got the message from the terminal server. 761-5159 worked fine.
I haven't heard any definitive theory as to the cause yet. One of the theories bandied about was that "something got dropped into the batteries". I looked at the actual battery case. It's totally enclosed, but the top plate of the box is perforated with numerous small holes. Inside the cabinet, the battery posts (lead, presumably) stick up, and are connected to each other with some sort of grey silver metal braid. I suppose a wire dropped in *just right* might slip through the holes, and could in theory land across 2 terminals and short out, but I kind of doubt it. For one thing, I think a pieces of wire small enough to slip through the holes would probably have been small enough to vapourize itself without much harm to anything else. For another thing, it would have had to drop through the holes vertically, then somehow twist itself around horizontally *and* manage to make a really good connection with 2 different bits of metal. The battery terminals would have been pretty well oxidized, and they are, after all, pretty small targets in an area consisting mostly of plastic and painted metal. I don't believe there were any fusible links. Fusible links are basically just low tech fuses, being nothing more than a short length of under-gauge wire; if the curcuit overloads, the theory is, the fusible link is the bit of wire that will go first, and it's generally located in an area where it's easier to fix, and less likely to cause damage. Fusible links are not suitable for high voltage or high current applications. For instance in a car the primary circuit between the battery & the starter generally has no fuses or circuit breaker of any sort. The current draw is too high to make a fusible link practical, and in fact the starter has a low enough resistance that it's not really feasible to tell the difference between starting the car, and a dead short in the solenoid. For a stationary installation like the computing center, either fuses or circuit breakers would be used. Of the two, circuit breakers are much more likely. For power loads of this magnitude, blowing either a fuse or a circuit breaker would have been a very dramatic affair. It would have generated a loud noise, lots of ozone, UV radiation, and vapourized stuff. (oil, insulation, wahtever.) Those big fancy power panels aren't just for show; one of their primary purposes is to protect the operators from the potential fireworks if a breaker under full load should go. In a big electrical substation, the breakers are kept outdoors along with the transformers in an area fenced off from ordinary mortals. The computing center wasn't big enough to rate the outdoors display; but it did have many large breakers and other controls located along a wall. These would probably have done a great job of protecting the rest of the building if a short had happened almost anywhere "downstream" of the UPS. I didn't see any evidence that the battery cases themselves had any sort of protection - and I'm not sure it would have been any more practical there than in a car in the starter circuit.
The one exploded car battery I saw seemed to have done so because of an internal spark caused by plates loosening from their buss bars. In the quest to save lead they had used less in these junctures and they can break and spark when there is a large current draw.
Back in Junior year of High School, I was in Auto Shop class, and the idiot they hired to be 'teacher's aide' hooked up a car battry to a charger, backwards. The explosion that followed only a few minutes later was quite violent. The case had cracked all around the battery, and the core was visible where the two halves of the case had separated. Acid flew every- where, but, fortunately, noone was anywhere near the area when the explosion occurred. What I remember most was how loud that explosion was...Batteries store a great deal of energy, and can be quite nasty......
The explosion was caused by hydrogen and oxygen recombining into water, not by energy stored in the battery. Being connected backwards it split a lot more water than it usually would as current flow through the charger was probably way in excess of what it was rated for.
Back to Grex problems. Twice today I have attempted to mail a 26K file to two Grexers and the mail has failed with the following uninformative message: ----- Transcript of session follows ----- ... while talking to grex.cyberspace.org.: >>> DATA <<< 554 SMTP-MAIL: died on signal 11 554 mooncat@cyberspace.org,gypsi@cyberspace.org... Service unavailable Have I discovered an intentional limit on e-mail size, or is this a bug?
I don't think #54 is correct. A battery generates hydrogen and oxygen by electroysis of the battery acid during charging, after the battery is fully charged. It does not generate the gases on discharge, which is what would be happening with the backward charger. I would expect that the explosion would result from heat generation.
I think you are correct. However, the space between the plates and the top of the case is filled with oxygen and hydrogen gas unless the caps are removed. The exploded batteries I've seen had the cases ripped apart above the electrolyte level but were intact below this level. Had the energy for the explosion come from the stored charge, I'd expect the lower part of the case to be shredded. I have also noticed gas bubbles while charging discharged lead-acid batteries before they were fully charged.
Could I please get a comment on my resp:55 from a staff member?
They're all too busy debating fires and batteries.
The explosion can be a result of a mix of things. The only gases generated in the battery is a stoichiometric mixture of H2 and O2, which really goes bang. The shorting of the battery can generate enough heat to probably melt connections and hence create sparks. Unless the battery is ventilated, it will retain that explosive gas mixture for quite a long time, from previous charging. And yes, the overvoltage used for charging can indeed produce some of the gas mixture even before the battery is fully charged.
Item 65.
Ken, I believe the limit on e-mail size is 100K, so I don't know why your mail was rejected.
is there any way to expand the time (30 seconds) grex allows for one to login once one gets a login prompt-- when there is a long que and one leaves the grex window open while the que is running, 30 seconds is often not enough time to catch the login while it is up. Maybe 60 or 90 seconds would be better.
How about if I increase it to 120 seconds, retroactive for the past year or two? <poof!> It's done. (and all without having root, too!)
Impressive.
oh, is it 120, well it seems like 30 seconds, maybe it should be upped to 180 seconds or 240.
Maybe you should pay attention. 120 seconds is two minutes when other people in the queue are being forced to wait because you are not paying attention.
also, is there a way to turn off !talk requests without turning of !tels? Or at least limit the number of times you can get paged for a !talk request to maybe twice. I hate it when complete strangers, usually new users, !talk me and I get paged for what seems like forever.
I thought this was a "non-problem" aka: "non-issue"..?
I think 120 seconds is reasonable. It *does* beep when it gives you the login prompt; this is supposed to get your attention. As for allowing tels and disallowing talk requests - I'm not sure if it's possible currently, but with the architecture of the write/tel program I don't think it would be too difficult to implement. I think that it's possible to get part of the effect you want by doing "mesg ne" and then specifying in your .yeswrite file (if that's the name) a set of people who are allowed to write/tel you.
how bout adding a couple more beeps If im in another window and I have a window to m-net open and idling it will beep three time....it tends to get my attention better than a single beep...
Please no more beeps.
Dialed in this evening to 761-3000 (no idea what line I wound up on) but got the "connecting.. this may take a minute" message followed by NO CARRIER. Happened several times running -- perhaps one (or more) of the dial-ins is messed up?
Nope, inetd had died somehow.
I had the same dial-in problem earlier this evening.
Hmmm.. I'd've thought that would've prevented me from ssh'ing in, too -- or was it fixed by the time I posted #73?
sshd generally isn't run from inetd. The reason is that inetd only launches a program when there's an incoming connection. That's a bad idea for sshd, because it needs to generate an encryption key when it's started, and that can take 15 seconds or so. So usually it's just allowed to run all the time, independantly of inetd.
Makes sense..
Running sshd and inetd independantly is also useful if one of them dies, since it's then possible to access the system using the other one.
Naah, that's what modems're for! :)
I dont really want to set up .yeswrite or .nowrite files because I dont mind getting tels, and it feels anitsocial in this environment to be using such files. I just want to permanently block any !talk requests because anybody !talking me should really be !teling me, and I have rarely ever had somebody !talking me from offsite. there isnt a way to do that?
Damn, that's racist and antisocial - you should let EVERYONE tel &
talk to you! At *ALL* times!
Sheesh..
its not racist, I dont mind if an Indian user !tels me-- some of them are nice-- I just dont want to turn off !tels just because I want to turn of !talk
Separationist!
I'm getting sick of being constantly !tel'ed and talked. I come to grex to do chat and I damn well aint going to start now. Wanna talk to me, send me an e-mail
I think being able to turn off talk requests without turning off tel's would be reasonable. I'd email janc about it - he's the author/maintainer of the write/tel stuff.
At very least, someone should hack the 'talk' source so it only pages you *once*, instead of repeatedly. It's a very rude program.
It's garb- errr.. "it's not a problem" .."it's not an issue"
(Hey, did anyone else notice that Peefv never mentioned any specific ethnicity, which Richard instantly pegged as Indian? Hell's yeah, I still got the instigator in me...)
It may not be a probelm or an issue, but I would like to be able to turn !talk off completely... I never use the program, and I don't like it.
Gee, youse guys make it sound like it's your RIGHT to control
the contents of yer CRT..
(while you are modding, set it up like bbs or party: user defined
filter-insertion)
Edit your .login file and make sure it has the lines
setenv MESG mesg
mesg n
If you change your mind, change that final character to a "y".
... or just do "mesg y" on the fly to change it for one session.
I wish I could backspace at the login: and password: prompts. And I'm not all that bad a typist.
You have a problem with your terminal settings. Your backspace key is probably set to send ^?, while login expects ^H.
Nope. I can solve *that* problem. But when I do, grex reports, "Not allowed to modify login" or words to that effect. And my terminal sends <CTRL>H, which gets displayed as "^H", of course.
Here 'tis: } (ttyr6) grex login: gelasdfk^?^H^?^?^?^H^H^H^H^H^H^?^?^?^?^?^? } You may not change $L0 } gelas's Password: Hmmm... This gives me an idea.
That did it: } login: abcd^H^H^H^Hgelinas } gelinas's Password: So I just have to carefully count how many <CTRL>Hs I need.
If you type whitespace on the login line, the extra parameters get converted to environment variables L0, L1, etc. Login checks for various extraneous environment variables (such as LD_LIBRARY_PATH) that have security implications, and rejects them. It uses the pattern L*, which has the side-effect of rejecting L0,L1 as well. It might not be obvious, but L0, L1 do have security implications -- sometimes people who fat finger their password manage to get it into the login prompt, and we don't want to export passwords or parts thereof into the environment.
I use ^U if I make a mistake on the login: or password: line, then I re-type it. It works great.
(Control-U is "erase line" in UNIX)
I don't understand why login can't treat *both* ^H and ^? as delete characters when logins and passwords are being entered. That seems the only sane solution. Only catch is that the change over would annoy anyone whose password includes a ^?, but any such person pretty much deserves it.
Oh, and I agree that there should be a way to turn off talk requests seperately from write/tel requests. Someone who has a couple days free should write this sometime.
Back there for the person who suggested 'mesg n' for the .login file... Doesn't that turn off *all* messages? I don't want that. I like tels, and I tend to talk to many people at once via tels while in party or something. What I don't like, or use is !talk...
if i remember correctly, the manual for mesg or for nowrite/yeswrite includes a flag to select between tel/talk/chat/all requests. i have a yeswrite file and am flagged for tels only.
mesg ne -p t -r y -b y -m l
mesg -2 -m -a -n -y -o -p -t -i -o -n -s.
i dunno, i spent half an hour and got it to do exactly what i wanted...
For those who were asking somwhere about making telk requests not beep at you, the manual makes it look like mesg -b y will do that.
I think what they said was they didn't want to: see, hear,
smell, taste, touch or SENSE "talk requests".
OTOH, they wanted to live without losing telegrams.
Question from arabella: has anything changed which would break the combination of "setenv TERM ansi" and the more pager? Today Leslie starts getting the message: "WARNING: terminal cannot scroll backwards". We don't think she changed anything in her configuration files.
it's not April Fool's??
10:11am up 10:26, 1 user, load average: 0.08, 0.01, 0.00
User tty login@ idle JCPU PCPU what
jor ttys0 10:06am 5 w
Yeah, something's not right. First a traceroute stopped at blackrose.org, then a couple minutes later it was hung up somewhere within cyberspace.org.
Late last night I found that I could not telnet to Grex from Michnet or tir.com; but when I dialed in I found lots of other people telnetted in. Today I can't telnet in from Michnet, tir.com, or msen.com, and apparently no one else can telnet in either.
Aruba says the two of us are alone on grex now. So why is it taking a minute or two to send off a short e-mail? All evening.
Grex's connection to the Internet is down. Blame Ameritech. Why is it taking you minutes? I don't know. Do you mean it took a long time for your mail client to accept the message? Are you using pine? If it's being delivered to someone else on grex, that should be no problem. But if you're trying to deliver to someplace out on the Internet, it won't get there until the link is fixed!
Sending to someone outside of grex, took over a minute to go from 0% to 100% using pine. Where did it go? Have not tried lynx recently. There are four of us dialled in at the moment, including someone in Party, signed on for 20 minutes. Who are they partying with? It takes two to party.
The long delay was probably something trying to do a DNS lookup, which requires network connectivity.
I had to wait several minutes at the "Welcome to Grex! (it may take a few seconds to connect)" prompt. Does that have to do with the net connection being down?
This morning it took 2:45 (minutes and seconds) to get from the Welcome to Grex to the login prompt using dial-in lines. And all my mail that I sent yesterday (which took over a minute per message to send) has mailerdeamon messages this morning saying it didn't go through.
Colleen, you're mail's not going anywhere until the Internet connection is fixed. There ought to be a large motd message explaining this, staff. I confirm the two minute 45 second wait for a login prompt.
The delay waiting for the login prompt was DNS timing out. That should be fixed now. Ameritech says they've found the ISDN problem, and are working on it.
Since it had been almost three hours since Ameritech had called to say it was a cable problem and was being actively worked on, I took a walk over to the Pumpkin to see if I could find any evidence of that. I started by walking around the building, looking for where the phone cables come out. I had assumed they came out the front of the building and then went straight up Huron to the CO, but there don't appear to be any overhead phone cables in that part of Huron. The phone lines come out of the side of the building, fairly near the back, and then head out behind the homeless shelter and the rental car place to Chapin Street. From there, they head towards Huron. I didn't have to follow them any farther than that. Near the corner of Chapin and Huron, there were two Ameritech trucks, next to two utility poles, maybe 100 feet apart. Running between them were a phone cable at normal height, and a another cable hanging down at about half the normal phone cable height. On each pole was an Ameritech guy. One of them was covered by a big cloth tent-type thing, so I couldn't see what he was doing. The guy at the other end had both cables split out into the individual wire pairs, and appeared to be going through, pair by pair, and replacing one cable with the other. It's currently drizzling and 43 degrees in Ann Arbor. It didn't look like pleasant work. Assuming they're doing what I think they were doing, we will probably lose each of the POTS lines briefly, one by one, as they work on this. I'm also guessing that we probably weren't the only customer affected, if they're replacing the whole cable. I wonder if we lost any of the dial-in lines, without noticing.
The net is up, but everything is extremely slow.
This response has been erased.
(Scott used to think ryan was cool)
Yeah, he should know sendmail is (or can be) load-sensitive.
I was amazed when I ran the sources of most of the SMTP-forwarded mail
on m-net against the local user database. It really was mostly from India
(or proxies like mason.ge.com that are American proxies for Indian sites).
To be fair, most of the POP3 abuse on m-net *was* from within the
'States, though most of it wasn't in the local user address database either.
This response has been erased.
What does Fatal exception in module kernel.dll mean? I got this both times that I exited the graphics conference. I am dialled in directly, using Procomm Plus/DOS.
It's a joke.
UNIX doesn't call dynamically linked libraries "*.dll".
more specifically, it's a dig at Microsoft Windows, which produces "Fatal Exception" errors with distressing frequency..
But both are neglecting to mention that the text is the 'exit message'
for the conference, much as diy (or is it micros?) says
Boop
when I leave it.
It's micros.
Grex hung up on me at 9:15 this morning. I was able to get right back on.
Just a few minutes ago I was on a dialin and experienced the now all too familiar disconnection without any reason.
does grex get a refund for the days or hours ameritech couldnt provide the ISDN service it was paying for? would seem only fair
Yes, I believe we are entitled to a refund. Our ISDN lines cost $48.05 each these days (including taxes and fees), so two days of service should be worth (2/30)*($48.05) = $3.20. Not sure if they'd pay for both days since we didn't call them until Friday evening, and they had it fixed within 24 hours of then. I'll give it a try.
Ameritech doesn't offer SLAs on those, do they?
What is a dynamically linked library?
Re #138: I don't know what an SLA is.
Re #139:
It is a file containing commonly used functions particular to Windows.
Windows aps depend on these files being there rather than have the code
compiled into the main executable. In theory it cuts down on disk space useage
by eliminating the redundancy of storing the same routines once for each
application.
Further, you can update those functions by dropping in a new libary, a new dll. "SLA" is "service-level agreement", a statement of what you get for what you pay.
SLA is most often discussed in terms of "support", up-time, response, 24/7, the like.
I don't know if we have a service-level agreement or not.
Right. Some ISDN providers guarantee a certain amount of "up-time".
I don't think Ameritech does but it's certainly worth a shot - if Ameritech
did offer an SLA, it'd certainly be an entire month's credit GREX would be
getting insteadd of a few days'.
Does UNIX also have GPFs? Or only Windows?
Unix has "segmentation faults". Same thing, a program tries to access something that it isn't supposed to.
Well... hehe - Actually, unix/linux segfaults are probably
easier to track down, since you can't ever be sure the GPF isn't
directly due to the virus they call an OS..
In unix, depending on the hardware, it's also possible to get an "illegal instruction", or "bus" signal, or sometimes a "bad argument to system call" or other interrupt.
Oy, geezus.. I had something like that "buss error" thing for
awhile.. Damned catchall is as bad as a GPF.. Fixed it, but gad..
It was depressing.
What SIGBUS means is hardware dependent, but originally (on the pdp-11 & vax), it meant an attempt to fetch a word on a non-word boundary -- an "alignment" error. Many modern machines can fetch words on non-aligned boundaries (usually with a small performance penalty) so this is not as likely. The i86 can do unaligned fetches. The 68000 and 68010 require everything except bytes be at even addresses. The 68020 and + can do aligned data fetches, but still require that the stack & program counter be even. The sparc and power risc architectures can't do aligned fetches. Most powerpc implementations can do aligned data fetches (but would require word aligned stack & instructions.) In openbsd, apparently, you'd have to do a systemcall that somehow invalidates the current stack or data segment; perhaps a call to mmap.
That was precisely the problem, too.. I had some code developed
(apparently) for DOS that relied on data being so & so arrayed..
I was pretty sure it was that, but I was too tired that day to
track it further.. Thankfully, another grexer took the reins and
slammed out a solution..
Sorta' a Terrible-Day & then the Sun-Came-Out, thang..
(Marcus, did you sometimes use "aligned" above when you meant "unaligned"?)
(Probably. Are you studying to be a proof-reader?)
(No, it's a curse.)
(Who's this General Protection dude, and why is everything always his fault? :)
He took over from General Mills.
/a is almost full, someone in party was complaining about a lost participationf ile.
Well, it's at 100% right now, and my part file was merely corrupted. I've not deleted it yet.
I lost my participation file to /a last night.
Time to put in one of those extra hard drives, and move half of /a to it.
Arrgh, are vandals attacking the /a drive again and filling it up? Im getting a "bad participation file" message every time I log on, and my conf bookmarks arent being kept upto date. How can I fix?
yeah, richard! quit taking up so much drive space! ;)
Keep a big junk file around, so when the drive fills up, you can delete it and get enough space to save your participation file. ;> (I'm kidding. Don't do that, it's not polite.)
HELLO STAFF?!? /a ihas now become a chronic problem.......
Yes, the /a problem just trashed another participation file of mine.
Why can't a link be used for certain groups' home directory to a known viable space on another volume. It seems that waiting to repartition doesn't fix the problem very fast.
I'd thought about that, or taking an additional step, and creating a
partition specifically for BBS partition files. The only advantage here is
that the volume would be easier to manage when conferences are dismanted (if
they are here, I haven't seen it happen, but it was a mess on m-net) - it's
still a limited volume and will still fill up. :)
I switched newuser over yesterday so that it is now creating new accounts on the /c partition instead. I fell asleep in the middle of trying to clear up space on /a.
It's a tough job, Steve. Good luck. Have you considered changing the
reaping times for inactive accounts?
How does one get switch the new menu system back to the old one?
Given that:
1) the people who intentionally vandalize the system by filling up
filesystems in a denial-of-service attack generally do so from
new accounts, not long-established ones, and that
2) "filesystem full" problems are of particular annoyance to conference
participants..
Would it be profitable to consider a home-directory allocation scheme
where long-established accounts with a history of mostly stable disk-
usage were grouped together on one or more partitions set aside for
the purpose? If the majority of long-time confer participants had home
directories which were physically segregated away from newuser accounts
it seems like many of the surprise filesystem problems which affect
Picospan users could be diverted..
That sounds like it would just be inviting trouble, though. Who would determine who gets to be a "special user" with a stable directory? Wouldn't giving accounts which are likely to lose their participation files to new users tend to make conferencing difficult for the people we're trying the hardest to attract to the conferences? It seems to me that the scheme John mentions in #168 would have a similar effect -- putting all the participation files someplace away from all the home directories would make vandalism less likely to trash them, right? -- but without discriminating between long-time conferencers and everyone else. Then again, I may be wrong.
Well, never attribute to malicious hackers what can easily be explained
by thousands of bored "software engineers" and other twits.
perhaps staff should identify these /a drive vandals and notify their ISP's and block'em if they are all coming from the same place
Or put a hard limit on the amount of disk space used by a user?
Gee.. what happened to the grex "we have no problem[issue]" speeches?
They vanished when you woke up.. Nobody's ever claimed that we don't have problems on Grex. The fact that we don't all agree with your approach to disk-space management doesn't mean that everyone thinks that the situation can't be improved.. re #176: The problem with enabling quotas is largely one of computational power -- the extra overhead for filesystem calls with quotas enabled on user filesystems would probably swamp Grex's fairly feeble processor(s).
Aww, that was cute.. Yeah, sorry: quota is too CPU-intensive.
I agree with Richard on this. ISP accounts are still mostly traceable to the perpetrators, and any ISP with half a brain is going to take a dim view of this sort of nonsense. As for a separate partition, this can be resolved fairly, maybe, with a 30 day? 60 day? wait before being moved to the stable partition. Certainly worth looking at. Clean up /a, then have all new arrivals start out on /b, and later get moved to /d (or whatever name is available) when we get to know them better. As for quotas: has this been experimented with to see just how bad the CPU hit would be? Perhaps a CPU upgrade is in order.
You're assuming that ISPs are always responsible for their users.
That's not always the case. I've had very bad luck contacting certain
administrations (as a system admin on other systems) - occasionally they'll
simply state that they're just not responsible for what happens with a wingate
proxy server on their network, since they do not directly administrate them.
M-Net's approach was to ban wingates when they were recognized (they have a
distinctive login prompt).
My impression is that the disk space fill-ups are generally a lot of people doing various stupid but probably not malicious things, that add up. When we get repeats of that sort of thing, from people who persist after being told to stop, we often do follow up with the ISPs. Sometimes it helps, sometimes it doesn't. However, the amount of work involved in tracking down the ISP of every eggdropping would be pretty staggering, and generally wouldn't help anything.
Actually, the simplest approach is to add more disk space. The fact this is becoming more & more of a problem is almost certainly an indication that we're way closer to capacity than we should be.
What was with the downtime & reboot this AM?
I couldn't dial in this morning - had to telnet.
Ping was refused; finger was refused; telnet was refused.
Load has been up over 20, we now have:
10:43am up 1:03, 65 users, load average: 9.44, 14.74, 13.34
Don't know that this is a "problem", but why, when I was reading the agora "man of the century" item, at the More prompt, did bbs display: (Fixed item 119 flags 38->18 mtime 382b073a) (Fixed item 119 rcnt 54)
Nice and speedy now, even at 2400. Way to go, staff.
I logged on once and got NO CARRIER after some gibberish. Second login got me to bbs with some gibberish along the way, but I can only read the first one to five lines of anybody's response then it turns to gibberish. Tried both 761-3000 and 761-5041. A new user also phoned (in Russian) to ask why he got NO CAREER instead of e-mail. (I can read what I am typing just fine, and this is line six already). Trying to read e-mail got me a line or two of readable e-mail plus gibberish, for each e-mail. We may have to go out and fix the NO CAREER problem for the Russians if it is not a grex problem, so would like to know before this evening if this is a general problem.
Tried to read my own previous response, read 1 line, the rest gibberish. Lynx is 100% gibberish except for Do you really want to quit? (I did). I am dialled in at 761-5041 right now.
I keep having NO CAREER problems, too, but I've been doing on-campus interviews, so hopefully they'll go away..
reboot NOW, avoid the rush.. Something is definitely WRONG when folks can leave party and we get NO MESSAGE in the log....
That can be done intentionally by judicious process killing, I believe.
keesan, the "gibberish" that you're talking about sound like a noise on a phone line with a non-error detecting modem. If I'm not mistaken, any modem speed 9600 or above will detect such gibberish, drop it, and ask the sending modem to transmit again. So noisy phone lines make things slow down but not fill with gibberish. Are you using a modem speed 2400 or below? If so, and given the popularity of 53,000 speed modems, I would expect that 9600, 14,400, and even 28,800 speed modems would be easy to find very cheap on the used market. If you are using an error detecting modem, then maybe the problem is the cable connecting the modem to the computer, the modem's power supply, bad modem interface, bad motherboard, or something like that. I very much doubt that it's a problem with Grex.
Kiwanis has a desperate need for external 14.4 baud modems
and internal modems of all speeds.
So dear user, if you or your company has some surplus, or soon
to be surplus, try to get them reused by getting them to Kiwanis,
Ann Arbor.
whats it...?
Kiwanis is a charitable organization. Several Grexers are active in the Ann Arbor chapter, which (among many other things) refurbishes old computer systems so people who couldn't ordinarily afford a new computer can still get a functioning machine suitable for at least basic word processing and e-mail..
I am currently on a tty which apparently has defective flow control to the modem. If this is the case, it would explain Sindi's problem too. The defective flow control screws up sz, so I am going to have to break my files into pieces that won't overflow the modem buffer before they encounter a software-enforced break in transmission. Oh, until it screws up, it runs *really* fast.
Every now and again, I get things like:
Ok: che
new resp items conference
--> 0 0 agora (where you currently are!)
3 0 coop
0 0 books
0 0 classicalmusic
0 0 scifi
0 0 micros
0 0 diy
0 0 rialto
chemie (4)
</UL>
<UL>Uni courses: 3. Fachsemester - winter 1952/53
<LI>605/606
Prof
.Frau Moufang: Analytische Geometrie II (5)
<LI>609 Dr.Burger: Einführung
in
die Funktionentheorie (4)
<LI>646 Prof.Dänzer: Physikalisches Praktikum
f&u
uml;r Physiker, Teil
II
(6)
<LI>661 Dr.Haase: Photographisches Praktikum (3)
</UL>
<P
>August 10 - 15:
Basel-St.Chrischona, V.Mennonite World Conference in der
Schweiz.
<P>I get a ride with the MCC people to Basel, Harold S.Bender rules as a
benign
pope. Peter J. Dyck
After the name, things just froze until the window went away.
What you are seeing is overloaded voice swiches thrashing as they deal with an enviroment of lots of data users over voice lines. Your 'onramp' to the 'information superhighway' is a dirt road and most 'data' users are driving lamborghinis. Get used to it. Or buy an ISDN or xDSL line.
I don't think so -- crosstalk problems with an analog connection are
just going to hose TCP performance, but with all the error correction
and detection at the hardware level, not to mention the complexity of IP
and TCP, it's just not at all likely that a noise phone line is going to
inject data into a telnet session in quite the way Joe reports here.
It does appear that something has managed to "inject" a tcp packet into
his telnet session which is certainly rather odd, to say the least.
Since it looks extremely random, it's probably a software glitch
somewhere, and not a purposeful mistake. It might be worth collecting
the data from multiple occurrences and seeing if there's any pattern in
them that would make it possible to determine where they come from. It
would also be worth doing a web search to see if the text can be found;
if it can, determing the offset and size of that text within the html
might provide some interesting clues. It might also be worth asking the
operator of that site if they have log records indicating when that page
was fetched, and if so, where it was fetched during a 5 minute window
surrounding Joe's hung session. If you can find out where that data was
*supposed* to go, then it should be easy to figure out where it got
misdirected.
Now, the places where the data could have gone astray include:
(1) grex -- but nobody else has reported this problem, so grex is not
likely
(2) the michnet dialups - a bug in the portmaster that copies other
people's data into your session?
Joe in fact appears to use mostly michnet dialups, plus some sessions
from a desktop machine at ITD, so--
(3) something at Joe's end -- if he's sharing his PPP connection with
something else, like a NAT, or a web browser, or something,
perhaps whatever manages that PPP connection has problems.
(4) some sort of really weird bug in Joe's hardware or software --
perhaps it's randomly inserting unused junk into buffers, or
the tcp stack is buggy, or something.
If the problem only happens on dialup connections, and Joe can't account
for this data within his household, then I imagine the michnet folks
would be very interested in this bug.
Perhaps so. But I can assure you that in the heart of 'Silicon Valley' I cannot get much more than a 28.8 connection (from everything from the Hyatt to a 'single point' in a house while I can get at least a 44.6 connection from my house in south chicagoland with the same exact equipment. (From SF proper down the CALTRAIN some number of tens of miles I have noted the same.) Thus I conclude that the more 'data' connections over a 'phone system' the more likelyhood of shitty performance. Voice telephone 'switches' rely on the concept of 'pauses' where somebody breaths and somebody else considers a response. The fact is with 'modem' communication over 'voice' lines there are no such things thus while a 'switch' may be able to 'handle' 100000 people speaking over the same set of copper (corroded and 'dirty') wires it may only be able to handle considerably less number of 'data' conversations. Don't rule out a funamental inability of the 'infrastructure'.
I don't think you have a large enough sample size to draw any conclusions as to switch capacity vs. communication speed. For all you know, chicago may use copper from a different vendor, or may not be faced with a phone system that is expanded as rapidly so can plan their trunk capacity better and not be pushing their circuits to the limit. I believe statistical multiplexors (which *do* rely on the gaps in voice communications) are pretty scarce now -- and a good thing too -- because as I understand it, 28.8K modems don't work *at all* on such lines. In any event, Joe's symptom just doesn't fit with this. A problem with the analog link could cause garbled data, long pauses, or actual lost data. Any of these will show up in ip as dropped, delayed, or slowed packets, and Joe would be complaining a lot about "network lag". Instead, he's looking at a logical error such as the sort PPP might make if its header compression algorithm got confused and sent a packet off to the wrong destination. Since PPP strips off and regenerates the TCP sequence number in doing header compression this is actually *very* likely.
(Which reminds me -- something else Joe might try is to turn off header compression.)
Grex just hung up on me.
I'm confused by Beady's remarks, as well. Almost all core switch
traffic is entirely digital, and has been for some time - a DS-0 is a DS-0
whether you're screaming your lungs off at a rock concert or whether it's
completely silent, and is only re-switched to a different path when there is
a network event.
This really is a fascinating problem. My bet would be with whatever
PPP server Merit is using (are they still Livingston Portmasters?) becoming
confused when routing or reassembling packet fragments. But I've never seen
anything like that from a Portmaster.
Re #202: I bet it's got more to do with the local copper...or even modem incompatibilities. Back when Michnet still had an 800 dialin, the best I could get from Alma to the *local* Alma dialup was 21,600 baud, but I'd get a full 28,800 to the 800 number -- which you'd expect to be the noisier connection. The new modems they put in here at Tech are finicky and sometimes won't talk 28.8 to my modem at all, and insist that I manually force it to fall back to 14.4.
Time to stop guessing, guys. I use ISDN from my home. I only use a standard modem when I am out of town, which I'm not right now. I think Marcus is on the right track: TCP injection. The only other machine on this side of the ISDN modem is not on the network right now. (If I plug it into the modem, the modem never hangs up, so that <expletive deleted> NT machine is generating *some* kind of network traffic even when no one is logged in to it. Blast.) Now, this isn't the first time I've seen this behaviour on grex. My thought was that it was something Backtalk was doing. I don't remember seeing it any where else. Note, though, that I don't use Backtalk. (That *is* the name of the web interface to Picospan, isn't it?) So far as I know Merit is still using Portmasters. However, I think I would have seen complaints about this in ITD's Online Consulting queue, or seen other discussion of it, if it were happening to other users. Just as you (and i) would expect other grex users to report it here, if they were seeing it. Tell you what. I'll start dumping the injections to a text file to report here. I'll also work through UM to see if Merit is seeing other complaints about this kind of behaviour.
It's true Jan Wolter (one of the authors of backtalk) does have a german background, and has worked in academia, but I still doubt a bug in his code is going to somehow go feral and start generating web pages containing german class lists. Backtalk is, in any event, an ordinary cgi script - it doesn't have the ability to hack into the kernel and munge another processes tcp connection - or even its own (apache is between it and the outside world.) Some ISDN connections still use header compression. If you've got knobs (virtual or otherwise) to twiddle on your end, it's certainly worth experimenting with them.
No knobs. Drat. Well, you probably know the conferences here better than I do; I'm just a newcomer. I've no reason to think the quoted text wouldn't appear in a response here. Apparently, you do.
What sort of ISDN equipment are you using on your end? Are you using NAT?
It's a 3Com OfficeConnect LAN Modem. Yes, I'm using NAT, and allowing "Automatic Incoming NAT".
I just had a really wierd thing happen, maybe related, maybe not. After waiting for a free port after it got down to 5 to go this appeared: Nov 19 00:21 Nov 19 00:21 40977 -1 23733 203.246.133.92 LOST HEAD Then when the port was free it only printed "Grex" and when I pressed enter or any other key a few more characters would appear until the standard grex login: prompt was in full view. But it wouldn't take my username it only displayed anohter 'login:" after every keystroke for dozens of prompts. finally it took my username, but not my password. I disconnected using my terminal program, and reconnected only to find that it connected me with this already 'open' port. ad I typed my password correctly and then disconected someone could have aped my account. What up?
I had that happen to me too, a month or so ago.
Extremely slow net connection?
Re #213: I've had that happen many times with Kermit for DOS. (STeve calls it "tty constipation".) When I used to start up Kermit, something weird about my system made it give me an error message about half the time. I can't remember what it said, exactly, but it was something about not being able to interface happily with the modem. If I then went ahead and tried to connect to Grex, the terminal would be constipated. I learned, after a few of those, to watch for the message when Kermit started, and if I saw it, exit right away and start it again. It almost always wasn't there on the second try, and then everything worked fine.
I got gibberish again today (on my 14.4 modem) and then a disconnect. I may have fixed the problem by unplugging the power from my fax-phone switch for 10 seconds. Last time the problem occurred at both 14.4 and 2400 connect speeds and usually my setup works perfectly Despite having five phone lines plugged into my switch (one through a 1-2 adaptor). Jim did something fancy with the system to make it work with extension phones, fax, phone, modem, answering machine, and maybe it gets overloaded occasionally.
I have to wonder where the NAT is occuring that's mentioned in #212
- if I'm reading correctly, the ISDN CODEC, which has either a DHCP-assigned
or static address associated with the point-to-point bonded ISDN connection
(mlPPP, I'd wager) is performing NAT on behalf of several hosts attatched to
it, which may either have dynamically assigned or statically assigned
addresses (in the RFC 1918 range), *but* that there is only one functioning
host attatched to the CODEC.
I thought about the possibility of a program associated with a tty
failing to die gracefully upon recieving a SIGHUP and spewing output to the
terminal after the original owner had logged off of the tty, but that'd be
more likely to be processed HTML via lynx than unprocessed HTML source.
Extra output from a background process also wouldn't cause the telnet session to "hang". In fact, however, there are at least 2 reasons why this shouldn't happen -- (1) telnetd can't open a master pty if the slave side is still "in use" by the previous owner, (2) when telnetd runs, it calls "revoke" on the line which should mark any existing descriptors "non-read/write".
Hmmm. I don't understand the reference to the CODEC. The IP address is assigned to the port on the Network Access Server, in this case a Portmaster (I *think* Merit is still using Portmasters exclusively). (And yes, Multi-link PPP is a possibility; I've configured my modem to establish a second link when network usage demands it. It's been a while since I got the link that busy. I usually see it when I insist on continuing to work with telnet and the web while FTPing files.) All packets come into the ISDN modem for the same address. The modem then figures out which host on my side is supposed to get them. And then the host has to figure out which window to display them in. Oh, and yes, I've assigned static addresses to the machines on my side of the network. (For instance, this Mac is currently 192.168.1.2.) But as noted, only one machine is actually on the network right now.
How do you change the spacebar prompt settings in party? A user was trying to change the menu and ended up getting stuck with having to space to talk, just like it used to be. They were quite frustrated.
:set space and :set nospace.
I think what you are calling an "ISDN modem" is what jazz is calling an "ISDN CODEC". It's definitely not really a modem -- they do make ISDN modems, but they're most commonly used for the ISP side of 56K connections (56K requires that one side of the connection be digital). I don't think I'd call it a "CODEC" either, but I don't have a better name for the box you evidently have at home which is doing the IP address translation. In any event, that box is certainly the prime suspect, quite possibly on conjunction with the portmaster (or whatever it is) that's at the other end.
That very same type of screen showed up in several responses in the rec.food.coffee newsgroup a few days ago. Might have been a bigger problem than just a few notes on grex.
Yup, I was using "ISDN CODEC" for what most people mean when they're
talking about "ISDN modems" - the box that sits between the ISDN line jack,
acts as a terminator, and may or may not route packets or manage PPP or mlPPP.
In this case it's clearly acting as a router if it's doing NAT, so "ISDN
router" would be my term of choice, but I didn't want to rule out the
possibility it was a fairly dumb serial device like a Motorola Bitsurfr.
I was thinking the ISDN router would be the likely culprit, but now
I'm wondering, since it doesn't seem likely that the router would recieve the
packet in question under normal circumstances - since there was only one box
sitting behind the router at the time the problem was seen - and it would be
unlikely that a third party could produce a packet that accidentally matched
a source/destination port pair and sequence number for a telnet session, and
that still wouldn't explain the connection hanging, something which I hadn't
read correctly before (and therefore didn't take into account).
I've always heard it referred to as an "ISDN pipeline," but that might be some company's proprietary name for them.
Pipeline is Ascend's name for its routers.
I think the technical term is "ISDN thingy". :)
ISDN router works. I know it's not really a modem, since modems convert from digital to analog and back, but that's what 3Com calls it, probably to avoid confusing J Random Dialup User with too much accuracy. ;)
Grex wouldn't know anything at all about the ISDN router. TCP header compression works by taking all the bits that are easily predictable (like the IP header, tcp sequence number, etc.), & throwing them out. They're put back into the packet by the receiving end. As long as the two ends don't get confused, there shouldn't be any problems doing this. However, in Joe's case, one end is also handling ISDN connections from N other users, and Joe's end is doing NAT translation. So both ends have at least the opportunity to get confused, and send packet data, with forged "apparently real" tcp sequence numbers out. These forged packets will contain someone else's data, which will explain Joe's confusion, and since the real sender doesn't know this packet was sent, the real sender's tcp sequence number will be behind the client's sequence number. So, when the real sender sends data to the client, the client will just toss it as "old" data. If Joe can, typing blindly, convince the other end to send enough data, he *might* be able to get it to resync, but that would definitely be a pretty desperate measure.
It just happened again: be played on the 3d: It would interfere with Monday Night Football. Or be confused with it.) So again not a good day for collegs ~ ~ ~ ~ ~ ~ than ho rCcg. Note the tildes. My cursor jumped from trying to enter the final 'e' in college to a spot six lines down, with random text added as displayed. I wonder what would have happened had I been typing in one of the other telnet windows I had open at the time? As before, the session hung until Grex closed it.
Some additional comments: I've been using my ISDN line since last November or December. The only thing that has changed is that I now use grex instead of confer.itd.umich.edu for my conferencing. Selective memory may be in play, but I really don't remember seeing this kind of problem before I started using grex.
I'm getting GOT errors and trashed participation files again.
Out of disk space again: /dev/sd2h 842574 748646 9671 99% /c /dev/sd1c 1944365 1749411 518 100% /a
Re 231: Looks like part of someone's vi session, somewhere.
Been an interesting morning - verio.net has twice fubared the routing into grex.. Here's the latest "wtf?": traceroute grex.org traceroute to grex.org (204.212.46.130), 30 hops max, 40 byte packets 1 as1-nmc.gylr.mi.voyager.net (216.93.16.131) 166.663 ms 169.280 ms 169.717 ms 2 gld-router-pool.freeway.net (208.137.20.254) 169.105 ms 169.477 ms 159.741 ms 3 216.93.15.61 (216.93.15.61) 179.115 ms 259.464 ms 179.715 ms 4 rtr1-ethX-X.mnpl.mi.voyager.net (209.153.156.65) 179.366 ms 249.469 ms 289.710 ms 5 rtr1-ser3-0-9-0.lnng.mi.voyager.net (209.153.151.17) 329.174 ms 289.448 ms 269.706 ms 6 border1-hssi16-0.arb.qual.net (198.87.206.1) 299.168 ms 289.464 ms 279.710 ms 7 border1-hssi3-0.dtw.qual.net (131.103.4.5) 289.175 ms 189.480 ms 209.693 ms 8 serial1-1.csr0.cv.oh.verio.net (131.103.4.18) 209.181 ms 219.471 ms 199.705 ms 9 serial1-0.csr8.or.il.verio.net (131.103.5.1) 219.175 ms 219.448 ms 229.729 ms 10 ord0-0.qualnet-0.verio.net (129.250.16.78) 249.164 ms 239.469 ms 319.709 ms 11 ord0-0.qualnet-0.verio.net (129.250.16.78) 269.146 ms 239.462 ms 229.765 ms 12 ord0-0.qualnet-0.verio.net (129.250.16.78) 289.090 ms 289.485 ms 259.712 ms 13 ord0-0.qualnet-0.verio.net (129.250.16.78) 309.144 ms 289.478 ms 359.696 ms 14 ord0-0.qualnet-0.verio.net (129.250.16.78) 299.142 ms 339.465 ms * 15 ord0-0.qualnet-0.verio.net (129.250.16.78) 399.525 ms 399.464 ms 349.706 ms 16 * ord0-0.qualnet-0.verio.net (129.250.16.78) 369.888 ms 449.500 ms 17 * ord0-0.qualnet-0.verio.net (129.250.16.78) 509.894 ms 449.465 ms 18 * ord0-0.qualnet-0.verio.net (129.250.16.78) 489.888 ms * 19 * * grex.cyberspace.org (204.212.46.130) 409.898 ms
re: #235: Yes, #231 records _my_ vi session, up until the s in "collegs" and following, which was popped in from . . . somewhere. It is another example of a recurring problem that I believe to be limited to grex.
OK, folks, here it is:
>Back to vans. It looks like the choices are 1999 Dodge 1500 (Transedan or
>Sapphire) and 1999 Cheverolet Express 1500. We've taken both for
>familiarisation drives (not extensiv added an HTML version of the judge's
rulin
g. It's at
<a
href="http://www.cyberspace.org/lawsuit/injunction.html">ht
tp://www.cyberspace.org/lawsuit/injunction.html</a>
</PRE><br clear=all><hr>
#267
of 300 by Jan Wolter (<a href=/cgi-bin/bt/vanilla/bio?login=janc>janc</a>) on
Fr
i Jul 30 00:44:57 1999:<p>
<PRE>A couple notes on where things stand and where
th
ey are going, as I
understand it.
What we have now is a "preliminary
injunction".
This prevents
enforcement of the law until further rulings. It is *not* a
rulin
g that
the law is unconstitutional. It is just a ruling that says that the
likeli
hood of the law being found unconstitutional is high enough that
people
shouldn't
be prosecuted under it until it has been examined
further.
The ruling is quite
sa
tisfactory - Judge Tarnow appears to have pretty
much accepted all the ACLU's
rea
soning, and even added some arguments
against the law that they didn't make.
Thing
s do not end here. Lots of different things could happen next, but
the most
like
ly
And it happened again:
>Cutting and pasting from window to another caused re-wrapping, but it iss
>QUstand that part about "there are still some males who believe
that lesbians..
." - could you explain what you meant there, Sonja?
</PRE><br clear=all><hr>
#6
of
12 by Sweet Pea (<a href=/cgi-bin/bt/vanilla/bio?login=simcha>simcha</a>) on
Tu
e Dec 27 08:14:31 1994:<p>
<PRE>Wow, are there a lot of women out there who must
be going out (read:
sleeping with) the wrong men! I have never had trouble
with
my "civil
rights" in bed! Im very mainstream,a nd believe that if you make
your
bed, you lie in it for any o
} I took time to rewrap the above to match what appeared on my screen. In
} at least the first instance, it is very clear that it is something from
} grex. I suspect the second is also recognisable (by some here) as being
} from grex.
Hmm... So it looks like it's either Grex or Grex's routers. I just turned off header compression on Grex's ISDN link, and also rebooted the Pipeline on Grex's end of it, since it seemed generally confused. Let me know if the problem goes away.
Actually, I can only let you know when it happens. ;)
filled again ... grex.cyberspace.org% df Filesystem kbytes used avail capacity Mounted on /dev/sd0a 109823 71181 27660 72% / /dev/sd0d 156783 131196 9909 93% /usr /dev/sd0e 706783 625481 10624 98% /usr/local /dev/sd0f 471183 211699 212366 50% /x /dev/sd2e 699223 565503 63798 90% /var /dev/sd4h 1952573 861289 896027 49% /var/spool/mail /dev/sd0h 284215 229821 25973 90% /bbs /dev/sd2a 31023 12073 15848 43% /rootbak /dev/sd2d 31023 12871 15050 46% /suidbin /dev/sd2f 62863 588 55989 1% /tmp /dev/sd2h 842574 750399 7918 99% /c /dev/sd1c 1944365 1720330 29599 98% /a g
When I tried to access my inbox in pine, I got an error message telling me that no such file existed.
I've finally figured out the problems I've been having with backspace on grex. Frankly, I'm surprised that the basic configuration inquiry does not automatically create a default file that simply includes the line: tset -Q -e<backspace> whatever that character might be. Since the newuser scripts *do* ask what to use for backspace, it would seem appropriate to modify the users .profile or .login to include this line. The difficulty stems from the fact that a simple stty erase <backspace> does not propagate to bbs. It's beyond me why. bbs fails to inherit TTY settings within its environment and I've been fighting with it ever since. So tonight I bashed and brooded over it until I came to this solution. Perhaps my effort will help other Linux users be able to use the grex system with less difficulty.
Hmm... My .login says:
if ($?prompt) then
stty intr '^C' kill '^U' erase '^H'
I don't know why it chose ^H, but that's the right choice for me. Maybe
because of the check newuser did?
You (gelinas) use csh and sno apparently uses bash (an sh variant..)
That's what he meant by 'bashed'. :/
Hope this reboot solves the "few seconds to connect" problem. It's been taking more than 80 seconds.
it went much faster for me this time than it has been going recently.
I just experienced an annoying flaw in the idle time manager. While composing a response offline, I saw both the 15 minute idle warning and the 5 minute boot off message simultaneously. The warning would have been nice since I was still present and accountable and could have easily reset the counter with a keypress.
....ooop, and now it's dragging again.
} Respond, pass, forget, quit, or ? for more options? !df . } Filesystem kbytes used avail capacity Mounted on } /dev/sd1c 1944365 1749828 101 100% /a
Yeah, for a while there I couldn't send mail because it was full and I have no children. Whatever that means. Plus I couldn't enter responses because of all the fullness.
We are getting a new disk added, but STeve is busy with other committments at the moment. He will add it he assures staff when he's finished with his other work (which hopefully won't be too long down the track). Please be patient until then (staff are well aware of the problem).
Somebody explain the facts of life to Katie ...
8-{)]
I know I can do a 'ls -als|more' to review the files I have on the system and remove some that where only meant to say a little while. I know others here can do the same. But us who use bbs are less than 10% of the system users. Anyway to get the word out to the other users?
just got no carrier immediately when I typed pine (twice), but mail gave no problems. From Kiwanis, where we pay for each phone call 10 c. Why?
RE: resp: 256 Just added a message to the motd.
Ok, what is the limit I should have in my directory? And is there any way to compress mail folders?
Others may have an opinion on how much disk space you "should" use;
my only recommendation is "as little as you can, but no less.."
As far as compressing mail folders -- most Unix mail programs won't
read/write compressed folders directly, so you won't be able to use
them while they're compressed, but for things you aren't actively
using, you can compress them using the "gzip" command from within
a Unix shell. For example:
grex% gzip -v -9 old_mail.mbox
old_mail.mbox: 50.4% -- replaced with old_mail.mbox.gz
Which would compress the file to slightly less than half its original
size (typically gzip compresses much better than 50% on text files,
actually. 70-80% compression is pretty common.)
grex% gzip -d old_mail.mbox.gz
or
grex% gunzip old_mail.mbox.gz
will restore your compressed file.
The disk space message looks pretty funny in my Backtalk window. :)
Well "quota -v" {"!quota -v" at a bbs prompt} suggests 1 megabyte (1024
kilobytes).
Yes, 1MB, though it's not dynamically enforced. Thanks, Mike. For naive and UNIX frigthened users, filebrowse writeen by Valerie allows compression of files amongst its many options.
Isn't there something you can set to have a file system-commpressed through chattr? Also, if I were to compress the files that I do use often and then just have a shell program to uncompress, run the program, and then compress, would the tradeoff between extra disk space and used computer cycles be any good?
Another thing that could be done as a stopgap until we get a new disk mounted is to graft some space from /tmp and add it to /a (if I recall, they are partitions on the same disk; otherwize there's probably some not-as-easy way to graft).
The entire point is moot, as long as the space is filled with
the same data, for the same reasons, repeatedly.
re #265: unless it's going to be quite a while before anyone can attend to the new disk, it'd be better not to mess with the partition layout of currently-active partitions.. besides, it would almost certainly take less time to hook up the new drive, partition it, newfs, and mount it, than it would to back up /a, re-do /tmp and /a, etc.. re #266: you really just can't deal with the fact that staff isn't interested in ruling Grex with an iron fist, can you? it seems like we've rehashed this over and over again: YES, the freedom afforded to users here on Grex allows some abuses, and YES, I'm sure there's a copy or two of eggdrop source (or whatever your latest bogeyman happens to be..) taking up space that we could use right now. but for the last time, NO, a couple of useless copies of eggdrop are *not* the real problem here..
Interesting... it looks like this is one of those indirect y2k things. Turns out at least one of the rare staffers that knows how to add another disk to Sun systems is too busy at his money job certifying that all systems are y2k compliant to have enough free time to actually install a disk.
I just got disconnected when one of the cats kicked over the phone. I demand Grex staff do something about this! ;)
If STeve can't get to it before then, as an early Christmas present to Grex I'll volunteer to install a new disk once I've gotten past my current state of end-of-the-academic-term madness.. Until I finish my final programming projects, though, I sadly can't spare any volunteer time.
Thanks for your offer, Mike! Thanks to STeve's wizardry, he got the disk usage down quite a bit, but still not in a comfort zone. Probably also assisted a little by people deleting some personal files per motd.
Special thank you to Grex staff (scott particularly) and users, and an apology. Scott took the time to tell me how to do some unix stuff so that I now know how to download files from grex to my computer. Other folks told me how to compress and uncompress files. The outcome was that I offloaded _ALL_ my old mail folders to my own computer for long-term storage. But some of those were huge files, and I probably exceeded all good-manners limits in doing so. So an apology to everyone who was slowed by my excessive use of bandwith in service to cleaning up my excessive use of disk space.
What do you mean by "STeve's wizardry"? What kind of things did he do to clear up space?
That's a good question. He never tells his secrets (=
Like any good magician would tell his secrets.. .<grins>
hehe (=
nand ttyt7 Wed 8pm 3days 26 23 vi RequestViewMW_ADSL.cfm Come On, sheesh..
for those of us less aware of the subtleties, would you explain what the significance of user nand editing a file called RequestViewMW_ADSL.cfm is?
I think he's trying to point out the 3days idle figure.
Which more than likely indicates that the pty's "stuck", not that nand has actually had a session open for three days..
Right. I'll just try and fix that shortly.
/var is full, which means party is not working.
Now fixed. Thanks, steve!
Thanks, folks.
Key response time has been crappy over the link recently. Lags of 10-20 seconds are not uncommon.
Pine has been freezing on me recently. Usually it happens when I use one control-something combination that requires another control-somthing combination -- that is, I do ^W for search or ^X for send or some such, and then if I try to do an additional control-key command like ^C to cancel either at the prompt that comes up, my connection just freezes entirely.
happens to me, too. I have been learning Mail. Jim's phone bill reflects problems with grex. We pay for 50 calls/month and usually stay about that. Last month was 143 calls. He said it took ten tries to send an e-mail. Is there a good chance the problems will be fixed, or should we switch service? It is 6 cents per extra call. A stamp would be cheaper.
I've had the problem with Pine freezing up, but only when using Microsoft telnet. Then, it happens fairly predictably. If I use a different telnet client, no problems. This may not be what you're experiencing, but you might give another telnet app a try.
Ugh, the telnet that comes with Windows 95 and NT 4 is so bad! Do Windows 98 or Windows 2000 come with the same lousy telnet client?
98 is the same. I haven't tried 2000.
Try CRT for telnet. I'm using it right now. You c an download it from the TUCOWS web site.
We direct dial and Pine still freezes up. Procomm or Bitcomm.
You have several choices: