Idle Computer Science skills are the Devil's playthings Ah, the sweet, sweet smell of Monday. What better way to start your week than combining it with the latest confession of wrongdoing from The Register readership in the form of our weekly Who, Me? column. Today's blast from the past comes from a somewhat unrepentant reader we shall refer to as "Charles". Take yourself back to …
I've done something similar, or rather a program I was in charge of for a security system. Turns out ext3 doesn't like millions of files in a directory (hindsight 20/20, yada yada). Didn't so much run out of inodes as made things nearly impossible to remove -- rm -rf of the top directory didn't work, rm * inside the directory just caused the shell concatenation limits to be hit and nothing to happen. For extra fun there was data outside that directory that needed to stay intact -- ended up writing a small program to loop over the files sequentially and remove them one by one. Took hours to run IIRC on a fairly fast disk subsystem...
Oops!
find is your friend
Not when even it was choking on the sheer number of files. Can't recall the exact problem at this point but could have just been too slow or was chewing up too much RAM given the degree of, ahem, filesystem abuse that had taken place.
Otherwise yep, that's a great way to recover from something like this.
Something to keep people up at night: what happens to a BTRFS volume that has this happen? Nothing good I imagine, but I suspect the solution is more "mkfs.ext4 and restore from backup" than "fix it" given how BTRFS handles certain things.
<i.Recursive algorithms the preferred method of killing a computer.</i>
Bah.
More than one way to skin a c*t (kill somebody's purdy compoota) :
1. Hard reset tool (hammer)
2. 240V directly onto any exposed terminals
3. Remove heatsink and let the CPU die a hot and bothersome death (not always effective)
4. Insert family of rodents into computer box with lots of food and water. Nature will take its course.
5. Iron fillings. Lots of these.
6. Empty a tin of Coke directly on the motherboard and do not wipe up. Bonus points if the motherboard is operational at the time of outpouring.
Others are there, but you get the gist.
Software algorithms will only make it perform undesirably, and can be fixed with the right PFY/knowhow.
Hardware algorithms will make it stop performing permanently. :)
Take your pick.
PS - block of cheese in the mainframe + family of rodents = great fun
That's a surprisingly new addition to most CPUs though, in the grand scale of things - the last CPU to not have it were (IIRC) Netburst P4s and Thorobed Athlons.
I dare say some more specialised chips had it, but from a consumer grade standpoint, I think that's where thermal cutouts started to be 'the norm'.
Steven 'this is just off the top of my head, correct me if I'm wrong, commentards' R
Today, yes. I have had literally that happen (brace broke, heatsink fell off) and have the machine survive with no observable ill effects, I'm using it to this day with a new brace.
Back in the day, that's another matter - I recall seeing a YouTube video specifically testing sudden heatsink detachment on Intel and AMD CPUs - the Intel one got throttled down instantly, the AMD one went up in smoke, also instantly: they did have a similar mechanism, but it was polled relatively rarely on the assumption that thermal runaway does take some time. That was true if the fan died; it was most certainly not true if the heatsink itself departed wholesale...
Incidentally, mine was an AMD and all this flashed before my eyes in the millisecond I realized the funny thump immediately followed by a 747 at takeoff I heard coming from the case could only be one thing - luckily, this happened much later, by then I was covered too apparently.
I'm partial to taking them out behind the shed and applying gunpowder and projectiles.
...which will leave the data-containing silicon bits largely recoverable in their plastic packages, and scattered to the wind to compound the problem. Not really a good way of doing anything other than getting visceral revenge on "that dang compootah!".
Now a hammer to the chips in question, that's cheap, effective, and 100% guaranteed...
Recursive algorithms the preferred method of killing a computer. .... JimPoak
Not many realise, JP, that is what is killing trading markets and stalling progress in education and employment in enjoyment. No original lead in a novel direction.
'Tis where Humanity currently be Stuck, Terrified and Terrorised?
Methinks So. The Evidence is Surely Plain Enough BroadBandCast for All to See with Lots More Yet to be Shown in Support of the Motion, Immaculately Born of SMARTR Notions ‽ .
... provided he’s show promise, otherwise out out out.
That’s not inventive, that’s just stupid. Wrapping it up in mollycoddling “curiosity” is bullshit. You can be curious without fucking things up.
If he didn't realise that the box that was created to do repetitive tasks quickly then took the very repetitive task and did it very quickly, then he’s missing the point. That’s not a BOFH, that’s a user with little knowledge making poor decisions.
If he didn't realise that the box that was created to do repetitive tasks quickly then took the very repetitive task and did it very quickly, then he’s missing the point.
This!
That’s not a BOFH, that’s a user with little knowledge making poor decisions.
The same act in a different context (that of a sysadmin, like the BOFH himself in the '90s) can constitute a BOFH's act.
Never letting the truth get in the way of a true story:
When I was an undergrad, back in the day when VAX systems were new, one of my class mates failed, due to too much time hacking and not not concentrating on coursework. So, what does a hacker do when he's just failed? So the story goes, he broke into the computer systems and gave himself a pass. Inevitably, he was found out and, in an amazing turn of events, struck a deal to show them how he'd done it, in exchange for a pass grade.
The irony was that he failed the next year due to getting involved in too much guild politics. He was granted a repeat of that year and eventually scraped together a pass degree.
The double irony is that he founded various software companies after leaving and managed to do reasonably well for himself.
For me it taught me a lesson in the differences between DOS and Unix.
The intent was to fill the user's disc quota by doing
echo "Don't leave yourself logged in" >> please_logout.txt
./script.sh
Under DOS invoking a batch file from a batch file terminated the old one unless you used "call". Under Unix it spawns a new process. Cue the system dying due to running out of PIDs!
I'm not sure if the system automatically recovered by killing the process or manual intervention was required. Fortunately it was the first week of the uni year, so most people blamed it being all the freshers doing silly things.
Under Unix it spawns a new process. Cue the system dying due to running out of PIDs!
Admins who don't set reasonable resource limits (setrlimit / ulimit) get what they deserve.1
I've seen this plenty of times at customer sites. They report some problem, and it turns out one of their applications has an inadvertent fork bomb or filled up a small /var partition or what have you. "Isn't there some way we can prevent this?" they ask. Yes. Employ a system administrator who actually knows the OS you're running.
1Granted, depending on how long ago this was, it might have been a UNIX variant that didn't have setrlimit. But setrlimit's been around for a while. Man page history says it appeared in BSD 4.1c, and while I'm not sure when AT&T UNIX picked it up (don't have my reference books handy), it was incorporated into POSIX.1 in Issue 4, Version 2, in 1994. As far as I can remember it was in all the UNIX variants I was using in the early 1990s. (I don't remember using it in anything in the '80s.)
Sadly been there back in the early 1980s being responsible for the systems support of a timesharing mainframe at a UK higher education establishment and had to spend considerable effort trying to address activities such as these by 'enthusiatic' (and in some cases 'malicious') members of the student body. While ultimate discipline was down to the academic authorities (not Computer Services) it was necessary to identify the core offenders and generally to take them aside and explain the impacts of their misdemeanours on others. Bearing in mind the very limited resources available (2 x 76 MB disk drives (RP04 formatted for 36 bit use) supporting a community of 20K plus students - yes you read that correctly : two sub-one hundred megabyte disk exchangable disk drives - any mis-use had an immediate impact. What was equally apparant was the distress on other (shall we say less clued up) students if their account was 'taken over' and they were unable to complete coursework. Sometimes more drastic action was needed of course but generally trying to deny access to the system was non-productive as they would generally have access to multiple accounts as a result of their actions.
Of course, now of that would have applied to the activities under taken while a student myself a few years earlier at a different establishment with an even smaller and more limited system.
.. as a schoolboy in the 1970s. We were allowed to use Birmingham University's ICL 1906A, mostly for Fortran and Algol 68 programming. I wrote a macro (= shell script) that recursively created subdirectories, just to see how many could be created. Apparently the operating system only allowed a limited depth of directories - 64 perhaps - and the macro exited with no harm done. Until the overnight accounting program ran, which had a much smaller limit on the level of nesting it could handle, and crashed.
When I got to school the next morning I was summoned by a teacher who had been contacted by the university, and was sent to the university computer centre to explain myself. Their main interest seemed to be in why I had done it, and they accepted my explanation of innocent curiosity.
I can't say that I ever took down a mainframe....but, I did have a pretty darned effective way of "ghosting" a user (Can't log in, can't log out, can't be forced off, etc.; The only way out is for the machine to be shutdown and restarted.). I'll refrain from giving any more details, since I'm not sure that bug on that particular system has been fixed, even though I found it 30+ years ago!
In my first sysadmin job I needed a serial connector to connect an HP server to its green-screen system console. There were none spare but a colleague put one together with a soldering iron, a few bits of wire and some wiring diagrams he found online. We plugged our home-made connector to the server and terminal and it worked. Up came the login prompt.
Within half an hour, the company network ground to a halt. No email. No access to network drives. No telnet access to servers. Nothing. The entire company dead in the water. Within minutes of removing the hand-made connector, everything returned to normal. Network collisions from the connector were believed to be the cause. No recriminations but I wish with hindsight that I'd held on to that connector...for research purposes...for a friend....
Yes, I wrote a script to pretend to be a login screen, on our PrimeOS system. This was in 1984.
But I never did anything to break the computer. What I did notice however, was that the line printer in one of the terminal rooms was particularly noisy when doing a line feed. I then wondered what it would sound like if I sent several line feeds to it. So I created a file with 1000 line feeds, and sent it. There was a lecturer doing a tutorial session in that room, or at least trying to. It was the room next door, and I could hear it. About 1 minute later an angry man runs into the room I'm in and shouted at me "did you do that?". I denied all knowledge, including knowledge of HOW to do it. He couldn't work out how to prove it was me, and left.
I did the same sort of thing (emulating a login prompt from one of a set of guest accounts to see who would could enter their credentials), although in this case it was a Novell NetWare system. The not-too-bright CS teacher at the high school typed in her admin account, and that gave me a chance to explore the Novell admin tools. Eventually, one of my fellow students ratted on me, and the whole thing got me kicked out of the CS course, banned from the credentials that helped entrance into university, and very nearly kicked out of the school.
Make him work as an unpaid student assistant, with his other option being getting kicked out of school.
That way you can give him all the crap work like cleaning up from stupid hackers (and make sure he knows he has to get approval from someone else before running a script he's written to "help" him with mundane tasks, lest he take the mainframe down again) and if he turns out to be bright and has reformed his ways you can offer him a paid job after he graduates.
Also back in the '80s Mrs Muscleguy was a CompSci student and a program she was running on the mainframe entered a loop and could not be shut down and for a time we were threatened with a large bill for the extra time used. But then her lecturers intervened and admitted students had not been taught how to properly kill routines and our family finances were not threatened.
We had two kids and I was on a PhD stipend somewhat less than the married dole (our income went up when we had to claim it), so the proposed amount would have been significant for us.
Ah, those were the days, when all the servers were named after LotR characters and places. I even knew some Vax commands back then, all forgotten now.
While he was doing it with his account - no problem. But the second round doing it at other users: No mercy. First is because he impersonated other users. Second is he knew it would cause problems, and still did it and just walked away. I don't like "leave bombs behind" people with such a low common sense.
Does anyone remember 'The Prisoner'? https://en.wikipedia.org/wiki/The_Prisoner
Where the man in charge (number two) has the most powerful computer and says to number 6 (Patrick McGoohan) to ask the computer any question and the computer will answer it.
So our hero types (slowly) 4 characters and puts this into the the computer, which starts making noises and then emitting smoke before it explodes.
What question did you ask it? says number two.
Our hero replies 'The one question that no-one can answer, WHY?'
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
