Even though I'm pretty sure I've run with init=/bin/sh and then typed "exit" at some point in my single-user session, I have absolutely no recollection of the results. I should try it on a few OSes and see!
Of course, his method of preparing to move offices (a common occurrence at IBM) was to
1. Take his (RS-6000) workstation home with him the night of the move.
2. Otherwise, just lock his desk.
He didn't have anything in his office but his chair, desk, and workstation.
Sync is not synchronous. When it is back to the shell there is no guarantee that data in memory is fully copied to disk.
However, it sets a flag that is reset when the copying is done. Sync will hang if the flag is set.
So the first sync arms the copy and sets the flag and is back to the shell.
The second sync starts, blocks at the flag. The flag gets reset and it is back to the shell.
So the 2nd sync going back to the shell is a guarantee that the first sync is fine and data is safe
When you have nice, well behaved users you'll not have problems that need solving. When things go awry - that's when you'll need to solve problems... sometimes even without pranks.
Before we had yp set up on the machines, we just copied the password file between them with a note "make sure you change your password on foo" since that was the one we regarded as authoritative and would copy that to bar.
One time, while adding a person to the /etc/groups file for write access to the web server, someone did rcp /etc/groups bar:/etc/password (I suspect it was muscle memory) and, well, now bar was unhappy and wouldn't let anyone log in... or even su to root to fix it. Found someone who had an open terminal and had them do a while 1 sync... and then powered the machine down and brought it back up. It wasn't happy, so started up in single user mode. Just needed to get the password file in there... but the terminal was 300h which didn't have a proper termcap entry for vi or emacs to work. I was a mudder and knew how to use ed... so ed /etc/password and then the contents of the minimal password file were dictated to me. When done, we got it back up and then copied the password and groups files to the proper spots.
Another time (and this was a prank), someone left themselves logged in and someone else created a directory path that was about 3000 characters long. /user/jsmith/I/will/not/leave/myself/logged/in/I/will/not/leave/myself/logged/in/ ... The problem with this is that `rm -rf` won't handle paths longer than 2048 characters long. So it didn't get removed "I'll do it later." You know what else doesn't like paths longer than 2048 characters long? fsck. So when the machine was rebooted/crashed at some point, the root volume (yea, user directories were on the root volume) failed to fsck... and failed to mount. Stuck in single user mode with the backup partition and reading the man pages for mount on the other machine we found how to force a mount without fsck and then had the guy who did the extremely long path fix it (and promise not to do it again) and got machines working.
NeWS had an interactive PostScript shell and almost no security so this kind of mucking about was trivial...
Unfortunately, it broke some pages that lab users needed for school. I later learned one colleague wasn't able to complete a homework assignment because of my prank.
Another guy wrote a program that forked 1000 copies of itself, nice itself to 19, did a sleep(0) and then exit. As soon as it got any cpu time, it would exit, but it never would as long as emacs was running. Meanwhile, the load (as displayed by xload) became a solid black box.
So the emacs guy would run 'ps -ef | grep procname | xargs kill' as root.
This meant that it had to get some cpu time to handle the kill, which took longer than a sleep(0) and was largely ineffective.
The second time this prank was done, the process was named 'ema'... which promptly also killed all instances of emacs too.
The third time this prank was done, the process was named 'et'. This happened to have also matched /etc/initd and the machine rebooted rather suddenly.