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

241–250 of 320 posts

Re: fork() can fail

#241

Post by blueskin_ »

dredmorbius wrote: post #224
mjevans wrote: post #216

Earlier quoted context omitted.

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).

Root has had the ability to assign negative nice values since long, long ago. Non-root users can only assign positive niceness. The range is -20 - +19. In theory this can give higher priority to a process, but if you cannot get into the run-queue at all (fork bomb), or the problem is in kernel space (e.g., I/O access, hang, or a kernel space loop), then it's not going to help you much.

Technically, non-root users can use negative nice, if they are explicitly allowed to in /etc/security/limits.conf

Re: fork() can fail

#242

Post by blueskin_ »

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…

Normal users can't make a directory at the root of the filesystem by design.

To write that safely, you'd test for the result of mkdir and cd to return success before deleting.

In a shell, you'd just go

    mkdir /foo -m 0700 && cd /foo && ${deleteallfiles}

Re: fork() can fail

#243

Post by jbb555 »

This to me is a good example of why exceptions in modern languages are good way to handle errors. In this case the user has basically ignored the error return from fork() and the accidentally used it in kill.

If fork() had thrown an exception for an unexpected failure then the user could not have accidentally ignored it in the same way.

I realize that this is not appropriate for a system call but it seems like a good example of why handling errors using exceptions is helpful sometimes.

Re: fork() can fail

#244

Post by jbb555 »

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.

Or exceptions in many languages for error conditions that you don't want to accidentally ignore.

Re: fork() can fail

#245

Post by blueskin_ »

pflanze wrote: post #215
pimlottc wrote: post #211

Earlier quoted context omitted.

"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

It's nice to have, but I wouldn't rely on it to save me - it's no replacement for checking return codes properly.

Re: fork() can fail

#246

Post by prof_hobart »

brazzy wrote: post #73

And this right there is why exceptions are a superior mechanism of announcing errors...

I'm quite liking Swift's optionals.

If it's possible for the call to fail to return an object, you declare its type as optional (add a ? to it) and then the calling code has to explicitly "unwrap" the return value to get to the actual object - they can't simply go

   var pid=fork()
   pid.kill()
as that would be a compiler error. Instead, they need to go

   pid!.kill()
The idea is that they should check for the pid object being nil before doing the unwrapping. Of course, it's still possible for the coder to ignore that (just as it's possible, and depressingly common, for coders to catch and then ignore exceptions), but that's going to be a conscious decision because the compiler is telling them that there's a possible error condition here.

Re: fork() can fail

#247

Post by jwr »

Alupis wrote: post #57
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…

Could you have not just checked to see if you actually created the directory and/or check to make sure you moved into the directory before proceeding with your destructive function? (Defensive Programming 101 really).

You do realize that this, in turn, creates a race condition, right?

Re: fork() can fail

#248

Post by BuildTheRobots »

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,…

What are these "Lions Notes" of which you speak? Google is not being helpful to me :(

Re: fork() can fail

#249

Post by ciupicri »

BuildTheRobots wrote: post #248
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,…

What are these "Lions Notes" of which you speak? Google is not being helpful to me :(

"Lions' Commentary on UNIX 6th Edition, with Source Code" http://en.wikipedia.org/wiki/Lions%27_Commentary_on_UNIX_6th...

Re: fork() can fail

#250

Post by aqrashik »

BuildTheRobots wrote: post #248
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,…

What are these "Lions Notes" of which you speak? Google is not being helpful to me :(

Lions' Commentary on UNIX' 6th Edition

http://www.lemis.com/grog/Documentation/Lions/

Post reply on HN