crandell@ut-sally.UUCP (Jim Crandell) (08/05/85)
> We have been running Unix 4.2bsd for a *long* time now, with very high > load averages every day. I guess it was inevitable, but strange effects > on many working programs have been traced to a common cause: > > /dev/null is full, and is overflowing! > > Anybody seen this problem before? Can anyone help? Unfortunately, this problem is very common. The primary cause seems to be, oddly enough, the USENET community. Many posters to certain newsgroups including (but not limited to) net.politics, net.religion, net.wobegon, net.cooks, net.putrid_rice_eaters, net.pigeon_kickers, net.grammar.nitpickers, net.fanatical_holycow_anti-iconoclasm_preservation_league_rumor_mongers and probably a handful of others, habitually instruct their would-be correspondents to ``direct flames to /dev/null'' or words to that effect. Now, any site that has a high rate of news posting typically has a correspondingly high rate of influx of flamage, but in many cases, this traffic is directed to /dev/null. The solution apparently is not straightforward, else someone surely would have discovered it by now. Avoidance measures should include identifying the offending flame-redirecting news posters and threatening them with detoxification if they refuse to mend their ways. But there still remains the difficulty of disposing of that flamage which has already accumulated. The majority of such material is extremely vitriolic stuff, laden with heavy metals and complex, hyper-stable organic radicals, and it thus is not easily eliminated from the system by natural means. Furthermore, its inordinately high temperature typically renders it fairly inimical to removal by manual methods. (It has been suggested that a daemon is unusually well qualified to deal with this particular task.) In conclusion, let me state simply that (a) yes, it's a problem, and (b) no, I don't know what the hell to do about it, either. -- Jim Crandell, C. S. Dept., The University of Texas at Austin {ihnp4,seismo,ctvax}!ut-sally!crandell
brown@nicmad.UUCP (08/06/85)
In article <2586@ut-sally.UUCP> crandell@ut-sally.UUCP (Jim Crandell) writes: >> We have been running Unix 4.2bsd for a *long* time now, with very high >> load averages every day. I guess it was inevitable, but strange effects >> on many working programs have been traced to a common cause: >> >> /dev/null is full, and is overflowing! >> >> Anybody seen this problem before? Can anyone help? > >Unfortunately, this problem is very common. The primary cause seems to >be, oddly enough, the USENET community. Many posters to certain newsgroups >including (but not limited to) net.politics, net.religion, net.wobegon, >net.cooks, net.putrid_rice_eaters, net.pigeon_kickers, net.grammar.nitpickers, >net.fanatical_holycow_anti-iconoclasm_preservation_league_rumor_mongers >and probably a handful of others, habitually instruct their would-be >correspondents to ``direct flames to /dev/null'' or words to that effect. >Now, any site that has a high rate of news posting typically has a >correspondingly high rate of influx of flamage, but in many cases, this >traffic is directed to /dev/null. > >The solution apparently is not straightforward, else someone surely would >have discovered it by now. Avoidance measures should include identifying >the offending flame-redirecting news posters and threatening them with >detoxification if they refuse to mend their ways. But there still remains >the difficulty of disposing of that flamage which has already accumulated. >The majority of such material is extremely vitriolic stuff, laden with >heavy metals and complex, hyper-stable organic radicals, and it thus is >not easily eliminated from the system by natural means. Furthermore, >its inordinately high temperature typically renders it fairly inimical >to removal by manual methods. (It has been suggested that a daemon is >unusually well qualified to deal with this particular task.) > >In conclusion, let me state simply that (a) yes, it's a problem, and >(b) no, I don't know what the hell to do about it, either. We have a hose attached to the back of our VAX (like some dehumidifiers), that leads to the nearest inlet into the local sewer system. All /dev/null stuff is fed into that hose. -- |------------| | |-------| o| HRD725U & PV9600 Mr. Video | |AV-2010| o| |--------------| | | | | | |----| o o o | | |-------| O| |--------------| |------------| VHS Hi-Fi (the only way to go) {seismo!uwvax!|!decvax|!ihnp4}!nicmad!brown
fbp@cybvax0.UUCP (Rick Peralta) (08/06/85)
In article <489@utastro.UUCP> nather@utastro.UUCP (Ed Nather) writes: >We have been running Unix 4.2bsd for a *long* time now, with very high >load averages every day. I guess it was inevitable, but strange effects >on many working programs have been traced to a common cause: > > /dev/null is full, and is overflowing! > >Anybody seen this problem before? Can anyone help? > What if you remove /dev/null will all of that data explode the machine if suddenly released ? Rick ...!cybvax0[!dmc0]!fbp "A likely story. I don't believe a word of it."
boyce@daemen.UUCP (Doug Boyce) (08/07/85)
> In article <489@utastro.UUCP> nather@utastro.UUCP (Ed Nather) writes: > >We have been running Unix 4.2bsd for a *long* time now, with very high > >load averages every day. I guess it was inevitable, but strange effects > >on many working programs have been traced to a common cause: > > > > /dev/null is full, and is overflowing! > > > >Anybody seen this problem before? Can anyone help? > > > > What if you remove /dev/null will all of that data explode > the machine if suddenly released ? I just finished speaking to a friend at Berkeley and he tells me that 4.2 has a booby-trap in it. They forsaw (sp?) that /dev/null might overflow and that some stupid SA might think to remove it, they added some code in the kernal that will make a vax (only vax mind you) impode. Think about it....... -- Doug Boyce Daemen College, Amherst NY UUCP : {decvax,dual,rocksanne,watmath,rocksvax}!sunybcs!daemen!boyce ARPA : boyce%buffalo@csnet-relay or boyce%daemen.uucp%buffalo@csnet-relay "If my calculations are correct, when the car hits eighty-eight miles an hour, you're gonna see some serious shit!"
pc@unisoft.UUCP (Paul Campbell) (08/08/85)
<oog> > >> /dev/null is full, and is overflowing! > >> > >> Anybody seen this problem before? Can anyone help? Do what everyone else does ..... post it to net.bizarre (postnews </dev/null) Paul Campbell ..!ucbvax!unisoft!paul
chrise@ihlpl.UUCP (Chris Edmonds) (08/08/85)
> /dev/null is full, and is overflowing! > >Anybody seen this problem before? Can anyone help? Redirect it to net.general like everyone else. :-} Chris Edmonds @ AT&T - Something or other, Naperville, IL
john@moncol.UUCP (John Ruschmeyer) (08/11/85)
]From: boyce@daemen.UUCP (Doug Boyce)
]Message-ID: <817@daemen.UUCP>
]Organization: Daemen College, Buffalo, NY
]
]> In article <489@utastro.UUCP> nather@utastro.UUCP (Ed Nather) writes:
]> >We have been running Unix 4.2bsd for a *long* time now, with very high
]> >load averages every day. I guess it was inevitable, but strange effects
]> >on many working programs have been traced to a common cause:
]> >
]> > /dev/null is full, and is overflowing!
]> >
]> >Anybody seen this problem before? Can anyone help?
]>
]> What if you remove /dev/null will all of that data explode
]> the machine if suddenly released ?
]
]I just finished speaking to a friend at Berkeley and he tells me that 4.2
]has a booby-trap in it. They forsaw (sp?) that /dev/null might overflow
]and that some stupid SA might think to remove it, they added some code
]in the kernal that will make a vax (only vax mind you) impode. Think about
]it.......
Oh, but what about all those SUN workstations running 4.2? Will they go up
in a supernova if /dev/null is removed?
--
Name: John Ruschmeyer
US Mail: Monmouth College, W. Long Branch, NJ 07764
Phone: (201) 222-6600 x366
UUCP: ...!vax135!petsd!moncol!john ...!princeton!moncol!john
...!pesnta!moncol!john
Disclaimer:
Monmouth College is a mecca for diverse opinions. It is, therefore,
highly unlikely that the above opinions are those of anyone but me.
Silly quote:
Around here we don't have cuisine. We have EATS.gordon@uw-june (Gordon Davisson) (08/15/85)
>> We have been running Unix 4.2bsd for a *long* time now, with very high >> load averages every day. I guess it was inevitable, but strange effects >> on many working programs have been traced to a common cause: >> >> /dev/null is full, and is overflowing! >> >> Anybody seen this problem before? Can anyone help? >The solution apparently is not straightforward, else someone surely would >have discovered it by now. I heard a rumor that BHT*'s Atlantis lab had developed something they called the Bottomless Bit Bucket, which was supposed to solve this problem. This was some time ago, however, and I haven't heard anything since. Does anyone out there know what became of this project? -- Human: Gordon Davisson ARPA: gordon@uw-june.ARPA UUCP: {ihnp4,decvax,tektronix}!uw-beaver!uw-june!gordon Bitnet: gordon@uwaphast (Sure it's an ugly nodename, but I'm getting up a petition to change it to phastvax. Mail me your votes...) Disclaimer: I have no connection with BHT* or any of its subsidiaries. * BHT is a trademark of Black Hole Technologies, inc.
elf@cylixd.UUCP (Leonard Bottleman) (08/20/85)
>> /dev/null is full, and is overflowing! >> >> Anybody seen this problem before? Can anyone help? >The solution apparently is not straightforward, else someone surely would >have discovered it by now. We've solved the problem of /dev/null filling up by sending the overflow to the synchronous ports on our DMF-32s (we're not using them anyway). We didn't have a problem with /dev/null filling up until somebody told our managers how to send memos with mail, and the rest of us automatically routed mail from our managers to /dev/null. Leonard Bottleman ihnp4!akgua!cylixd!elf
inc@fluke.UUCP (Gary Benson) (08/28/85)
>> /dev/null is full, and is overflowing! >> >> Anybody seen this problem before? Can anyone help? > We've solved the problem of /dev/null filling up by sending the overflow > to the synchronous ports on our DMF-32s (we're not using them anyway). We mere^ly renamed it /dev/full, archived it to ma@g tape, dumped core and rebooted. Sa$d to say, there were a f%ew stra*y bytes left b&ehind. At leas!t the(y are in the ASCII range from 20 through 30 so they're ea*sy marks for our vacuum_unidentified_bits pro%gram (which is just a su)bset of our famous eat_extraneous_first_line program$). My second fav&orite program here is insert_standard_silly_replace_message. There are 4 contenders for my *most* favorite: how_much_does_Ruschmeyer_owe_me display_true_meaning_of_colored_stickers_on_mail unsubscribe_and_time_typing_speed rot-13_and_save_to_named_file *** REPLACE THIS LINE WITH YOUR MESSAGE *** *** ERCYNPR GUVF YVAR JVGU LBHE ZRFFNTR *** -- Gary Benson * John Fluke Mfg. Co. * PO Box C9090 * Everett WA * 98206 MS/232-E = = {allegra} {uw-beaver} !fluke!inc = = (206)356-5367 _-_-_-_-_-_-_-_-ascii is our god and unix is his profit-_-_-_-_-_-_-_-_-_-_-_