Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Unix Recovery Legend (1986)

ee.ryerson.ca

Post reply on HN
Print view View original

51–60 of 63 posts

Re: Unix Recovery Legend (1986)

#51

Post by aardvark179 »

duaneb wrote: post #49
JoshTriplett wrote: post #48

Earlier quoted context omitted.

I can think of one way to write "cd" out-of-process from the shell: exec /bin/cd /some/path, which does chdir("/some/path") and execs your shell. You'd lose your history and similar state, but if you had a shell that didn't even put cd in-process, it probably doesn't have history either. Sample: /tmp$ exec /tmp/cd /bin /bin$ exec /tmp/cd /home /home$ exec /tmp/cd /usr /usr$ Sample code: #include #include #include int…

Hah, hadn't thought of that. Kind of CPS for processes. I'm not sure what that would gain you, though, as you'd have to either a) write both the cd and the user of the cd, and there are less awkward ways to do that than exec'ing, or b) you'd have to pass something ELSE to exec to return control after cd finishes. This seems a little awkward and I'm not sure what is being proven. :P

It's how very early version of Unix effectively did stuff, they exceed a program, and when it exited they exceed the shel again.

When they introduced something like the fork/exec model we now have they discovered cd didn't work any more and had to write it as a built in.

Now, for bonus points, work out how goto worked when it wasn't a built in.

Re: Unix Recovery Legend (1986)

#52

Post by Joeri »

bitwize wrote: post #15
acveilleux wrote: post #2

I've had to do something similar a long time ago in the mid-90s when Linux switched from libc5 to glibc6. In this case, I hadn't deleted everything, rather I'd stupidly upgraded libc locally. After learning a valuable lesson in exactly how dynamic library work and the recommended process for live libc upgrade (don't do it if ABI changes) I fixed it by using my IRC client which was already running so unaffected to get…

That's why I freakin' love Slackware. The ability to repair stuff by hand, or even to get libc6 binaries running on a libc5 system (by putting the appropriate .sos in /lib), was a godsend during my early Linuxing, and completely unthinkable under Windows. It's very nearly unthinkable under Ubuntu or Fedora, but Slackware just keeps chugging the best it can no matter what shape you bash it into.

To be fair to windows, its backwards compat is legendary. I'm still using windows software on windows 8 that was last compiled in 1997.

Re: Unix Recovery Legend (1986)

#53

Post by PhasmaFelis »

wsterling wrote: post #45
charonn0 wrote: post #36

Earlier quoted context omitted.

> Alternatively, we could get the boot tape out and rebuild the root filesystem, but neither James nor Neil had done that before, and we weren't sure that the first thing to happen would be that the whole disk would be re-formatted, losing all our user files. (We take dumps of the user files every Thursday; by Murphy's Law this had to happen on a Wednesday). Another solution might be to borrow a disk from another VAX…

Yea, I am not buying it. They have a UNIX guru that is building new commands in assembly and transferring the files with uuencoding but no one knows how a recovery tape works? Using a recovery tape was not a rare event in UNIX shops.

Mario Wolczko's home page is here: http://www.wolczko.com/ Feel free to drop him a line and tell him he's a liar.

Re: Unix Recovery Legend (1986)

#54

Post by teddyh »

amyjess wrote: post #12

I first found this story in a collection of Unix horror stories several years ago: http://www.yak.net/carmen/unix_horror_stories If you enjoyed this one, you'll probably enjoy the others in there as well.

See also COMPUTER-RELATED HORROR STORIES, FOLKLORE, AND ANECDOTES:

http://wiretap.area.com/Gopher/Library/Techdoc/Lore/rumor.ne...

Re: Unix Recovery Legend (1986)

#55

Post by smhenderson »

davidw wrote: post #18
smhenderson wrote: post #17

Earlier quoted context omitted.

I'm curious to see what your tcl code looks like. Did you keep it around for future disasters or was it just a quick and dirty one-off?

It was as quick and dirty as could be. It was pretty simple, really, as it just accepted a connection and wrote a file with no encoding. No security or concurrency or any other niceties.

Ah, got it. Sounds like it did the trick though, a clever idea to come up with in the midst of looming disaster! :-)

Re: Unix Recovery Legend (1986)

#56

Post by JoshTriplett »

aardvark179 wrote: post #51
duaneb wrote: post #49

Earlier quoted context omitted.

Hah, hadn't thought of that. Kind of CPS for processes. I'm not sure what that would gain you, though, as you'd have to either a) write both the cd and the user of the cd, and there are less awkward ways to do that than exec'ing, or b) you'd have to pass something ELSE to exec to return control after cd finishes. This seems a little awkward and I'm not sure what is being proven. :P

It's how very early version of Unix effectively did stuff, they exceed a program, and when it exited they exceed the shel again. When they introduced something like the fork/exec model we now have they discovered cd didn't work any more and had to write it as a built in. Now, for bonus points, work out how goto worked when it wasn't a built in.

> It's how very early version of Unix effectively did stuff, they exceed a program, and when it exited they exceed the shel again.

Makes sense, since those systems might not have enough memory to run the shell and another program at the same time.

Re: Unix Recovery Legend (1986)

#57

Post by acveilleux »

Joeri wrote: post #52
bitwize wrote: post #15

Earlier quoted context omitted.

That's why I freakin' love Slackware. The ability to repair stuff by hand, or even to get libc6 binaries running on a libc5 system (by putting the appropriate .sos in /lib), was a godsend during my early Linuxing, and completely unthinkable under Windows. It's very nearly unthinkable under Ubuntu or Fedora, but Slackware just keeps chugging the best it can no matter what shape you bash it into.

To be fair to windows, its backwards compat is legendary. I'm still using windows software on windows 8 that was last compiled in 1997.

At one point I used a production proprietary DB engine last compiled in that time frame on Linux.

The hoops needed to run it on semi-modern Linux was a real PITA (think chroot jail and some ld shenanigans to patch shared libs). Microsoft's backward compatibility is reallly hard to do.

Re: Unix Recovery Legend (1986)

#58

Post by acveilleux »

JoshTriplett wrote: post #48
duaneb wrote: post #5

Earlier quoted context omitted.

You can't change the environment of the parent process, including CWD. `/bin/cd` would either be another process like all executables run by the shell, and not work, or special cased, at which point why make it an executable at all?

I can think of one way to write "cd" out-of-process from the shell: exec /bin/cd /some/path, which does chdir("/some/path") and execs your shell. You'd lose your history and similar state, but if you had a shell that didn't even put cd in-process, it probably doesn't have history either. Sample: /tmp$ exec /tmp/cd /bin /bin$ exec /tmp/cd /home /home$ exec /tmp/cd /usr /usr$ Sample code: #include #include #include int…

This would cause an eventual exhaustion of process table entry / pid and/or addressable memory as the previous shell is left in the background.

Re: Unix Recovery Legend (1986)

#59

Post by cperciva »

acveilleux wrote: post #58
JoshTriplett wrote: post #48

Earlier quoted context omitted.

I can think of one way to write "cd" out-of-process from the shell: exec /bin/cd /some/path, which does chdir("/some/path") and execs your shell. You'd lose your history and similar state, but if you had a shell that didn't even put cd in-process, it probably doesn't have history either. Sample: /tmp$ exec /tmp/cd /bin /bin$ exec /tmp/cd /home /home$ exec /tmp/cd /usr /usr$ Sample code: #include #include #include int…

This would cause an eventual exhaustion of process table entry / pid and/or addressable memory as the previous shell is left in the background.

There's nothing being left in the background. It's one process which is calling exec repeatedly; no forking going on.

Re: Unix Recovery Legend (1986)

#60

Post by cperciva »

irishcoffee wrote: post #26

One of my coworkers was out in the field trying to fix a problem on a rhel box. As root, typed in chown -R nobody:nobody / some/dir/somewhere/ Ended up having to re-image the system. We still give him a hard time about it. Now I'm wondering if he could have tried to find a more creative solution as displayed in TFA. Thoughts? Edit: He hard killed the box right after he typed that in.

Bogus file ownership won't prevent you from booting in single-user mode. And once you boot in single-user mode, you're running as root so you can change file ownerships back.
Post reply on HN