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

fork() can fail

rachelbythebay.com

Post reply on HN
Print view View original

211–220 of 320 posts

Re: fork() can fail

#211

Post by pimlottc »

davvid wrote: post #187
staunch wrote: post #67

Earlier quoted context omitted.

$ mkdir /tmp/foo && cd /tmp/foo && touch bar.txt

Yes. Always chain sequential commands with &&. Always. This style is pretty prevalent when writing test cases in shell (or just shell scripts in general), e.g. when using something like sharness[1]. [1] https://github.com/mlafeldt/sharness

"bash -e" has much the same effect: it basically exits on the first failed command, with considerations for pipelines, conditionals and the like.

http://www.gnu.org/software/bash/manual/bashref.html#index-s...

Re: fork() can fail

#212

Post by [deleted] »

davvid wrote: post #187
staunch wrote: post #67

Earlier quoted context omitted.

$ mkdir /tmp/foo && cd /tmp/foo && touch bar.txt

Yes. Always chain sequential commands with &&. Always. This style is pretty prevalent when writing test cases in shell (or just shell scripts in general), e.g. when using something like sharness[1]. [1] https://github.com/mlafeldt/sharness

[deleted]

Re: fork() can fail

#213

Post by derefr »

kabdib wrote: post #209

When I was young and really didn't understand Unix, my friend and were summer students at NBS (now NIST), and one fine afternoon we wondered what would happen if you ran fork() forever. We didn't know, so we wrote the program and ran it. This was on a PDP-11/45 running v6 or v7 Unix. The printing console (some DECWriter 133 something or other) started burping and spewing stuff about fork failing and other bad things,…

> ...a minute or two later one of the folks who had 'root' ran into the machine room with a panic-stricken look because the system had mostly just locked up.

It's kind of weird that, while root has always had e.g. 5% reserved disk space on the rootfs for emergencies, one thing no Unix has ever done is enforce a 5% CPU reservation for root so administrators can "talk over" a cascading failure. I think this is possible just recently in Linux with CPU namespacing, but it's still not something any OS does by default.

Re: fork() can fail

#214

Post by hollerith »

swah wrote: post #29
cperciva wrote: post #7

This reminds me of one of the most epic bugs I've ever run into: mkdir("/foo", 0700); chdir("/foo"); recursively_delete_everything_in_current_directory(); Running as root, this usually worked fine: It would create a directory, move into it, and clean out any garbage left behind by a previous run before doing anything new. Running as non-root, the mkdir failed, the chdir failed, and it started eating my home directory…

In those times I wish I could use the emacs lisp way: (let (dir "/foo") (create-directory dir) (with-current-directory dir (delete-all-files-recursively))) Factor recognized the value of dynamically scoped variables: http://concatenative.org/wiki/view/Factor/FAQ/What's%20Facto... A lot of code became much simpler because of that decision.

I fail to see how dynamic scope pertains to the code you wrote or helps avoid the bug described in grandparent.

Specifically, the code you wrote would behave the same if `dir` had lexical scope.

Re: fork() can fail

#215

Post by pflanze »

pimlottc wrote: post #211
davvid wrote: post #187

Earlier quoted context omitted.

Yes. Always chain sequential commands with &&. Always. This style is pretty prevalent when writing test cases in shell (or just shell scripts in general), e.g. when using something like sharness[1]. [1] https://github.com/mlafeldt/sharness

"bash -e" has much the same effect: it basically exits on the first failed command, with considerations for pipelines, conditionals and the like. http://www.gnu.org/software/bash/manual/bashref.html#index-s...

Note this recent discussion about bash -e, including my post that "the disappointment with set -e is that it does not work everywhere".

https://news.ycombinator.com/item?id=8054440

Re: fork() can fail

#216

Post by mjevans »

derefr wrote: post #213
kabdib wrote: post #209

When I was young and really didn't understand Unix, my friend and were summer students at NBS (now NIST), and one fine afternoon we wondered what would happen if you ran fork() forever. We didn't know, so we wrote the program and ran it. This was on a PDP-11/45 running v6 or v7 Unix. The printing console (some DECWriter 133 something or other) started burping and spewing stuff about fork failing and other bad things,…

> ...a minute or two later one of the folks who had 'root' ran into the machine room with a panic-stricken look because the system had mostly just locked up. It's kind of weird that, while root has always had e.g. 5% reserved disk space on the rootfs for emergencies, one thing no Unix has ever done is enforce a 5% CPU reservation for root so administrators can "talk over" a cascading failure. I think this is possible…

It would only be possible if a limit were enforced on all non-primary namespaces.

However something that has been /possible/ for a while (but not in practice done) would be to elevate root process priority over other processes. Probably not done due to daemons needing to run as root (which is decreasing as they're able to drop privileges these days).

Re: fork() can fail

#217

Post by donatj »

nwmcsween wrote: post #184
donatj wrote: post #159

And this is why I think Go-lang and its multi-return is the way of the future. In Go you are required to handle errors. If you want them to go away you have to explicitly use an _ and thats really easy to find in the code and shame the person who did it. Nothing fails silently. Nothing fails via primary return. It is such greatness it is hard to express.

You can easily do multi-return in c, return a struct it just doesn't hold your hand.

But as a language construct and the agreed upon way of returning errors it's much more powerful. Returning a structure you can just ignore the error piece. Returning an error however in Go, you have to explicitly handle it. If you don't, it's literally a compile error.

Re: fork() can fail

#218

Post by rwallace »

Alupis wrote: post #131
yosefk wrote: post #124

Earlier quoted context omitted.

Taking the square root of a negative number removing all the files in your home directory could be "well defined and clearly documented behavior". Would you blame the API author at that point or would it still be strictly your fault? At what point do API authors share the blame for a needlessly harsh punishment delivered upon a predictably common error? I certainly prefer to work with systems produced by people tendi…

I could argue, however, that in this particular case, it's the user's fault for failing to understand the full and defined behavior of fork() in addition to failing to understand the full and defined behavior of other functions, ...say, kill(). It's just as wrong to feed kill() -1 as it would be to feed it -48585 or "babdkd" (unless that is explicitly your intention). A simple sanity check of if [ "${pid} > "0" ]; is…

Fault is not a rivalrous good. It's the user's fault, and it's the API creator's fault.

Is there a reason fork can't be changed to just crash the program on failure? Are situations where a program usefully does something other than crash on fork failure, more or less common than situations where a program fails in the way described in the article?

Re: fork() can fail

#219

Post by pflanze »

mutation wrote: post #18

Just noticed that in Perl the behavior is slightly different: http://perldoc.perl.org/functions/fork.html unsuccessful fork() returns undef, effectively stopping you from kill-ing what you don't want to kill.

Interestingly, the kill procedure in Perl explicitely checks for non-numbers, which is unusual. Perl as a language would just cast undef to zero in a numeric context[1], and 'kill $signal, 0' would go on killing every process in the process group.

  $ perl -we 'kill 9, undef'
  Can't kill a non-numeric process ID at -e line 1.
[1] unless you "use warnings FATAL => 'uninitialized';"

Re: fork() can fail

#220

Post by lmm »

takeda wrote: post #136
_yosefk wrote: post #130

Earlier quoted context omitted.

Nothing in C forces the API designer to use -1 as "bad PID" in one place and as "the set of all PIDs" in another, however. Perl's undef isn't that different from returning, gosh, -2 or any other bloody number except -1 in C.

Actually this is not true. fork() returns pid_t type which is usually mapped to int32_t. For this type there's no equivalent of Perl's "undef", the -1 is standardized as an error in all system calls that return an integer. As for the argument why not send -2 instead, well guess what? Other negative values also have a meaning. Negative values in kill send signal to a process group instead of a process. It's not libc r…

> As for the argument why not send -2 instead, well guess what? Other negative values also have a meaning. Negative values in kill send signal to a process group instead of a process.

That's the problem there. Kill takes an argument that's either a process id or a magic number or a different magic number or.... Those should be different functions, and the special cases like "kill all processes", "kill all processes in this group",... should be some kind of enumeration type. But it's C, so...

Post reply on HN