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

271–280 of 320 posts

Re: fork() can fail

#271

Post by ZoFreX »

yokom wrote: post #79

I don't use fork() that often, but my own paranoia is why I always test for if len(some_list) But it's just my way of covering my ass in case the laws of physics change during execution, or just in case weird bugs exist like those found in this article.

> just in case weird bugs exist like those found in this article

The article does not describe weird bugs - the behaviour it describes in fork() and kill() are by design, and well-documented. The real lesson here is to RTFM and understand what return values you get under what circumstances.

Re: fork() can fail

#272

Post by hderms »

mnw21cam wrote: post #261
dllthomas wrote: post #80

Earlier quoted context omitted.

I wonder if it would be worthwhile to forego the notion of a CWD for processes entirely.

CWD is a useful concept. If I run gimp in a particular directory, I'd like it to show that directory in the file dialogue when I try to load or save an image. What is evil is a program changing its working directory. That's when it becomes an evil global variable, rather than a non-evil global constant.

I think that's probably the best way to look at it. You are given the parent node with CWD and you can attempt to modify child nodes by relatively addressing them.

I was wondering before if it would be interesting to have a filesystem with transactional locking of paths, though I'm sure the performance would take a hit. Would be kind of cool to be able to do filesystem operations without constantly opening yourself up to race conditions and requiring extremely defensive programming.

Re: fork() can fail

#273

Post by nathan_long »

mkehrt wrote: post #108
AnimalMuppet wrote: post #84

Earlier quoted context omitted.

Is this just using some vague connection to ride on one of your favorite hobby horses? Or does this have a connection to the article, and I missed it?

The problem is that C and POSXIX don't (idiomatically) provide rich enough data types force checking the error condition. The fact that the error is signaled by a random integer (-1) is horrible. In a language with stronger types and richer data structures, one can have a return type that is a disjunction of {failure, parent, child}, so you can never accidentally treat a failure as a PID. In a functional language thi…

Raising an exception would also work.

Re: fork() can fail

#274

Post by Mister_Snuggles »

tracker1 wrote: post #204
Mister_Snuggles wrote: post #170

This reminds me of the time I was telnet'd (since SSH wasn't a thing at the time) into a remote SunOS/Solaris server. At the time my only Unix experience was with Linux. "killall -9 httpd" gave an unhelpful error message. "killall httpd" also gave an unhelpful error message. "killall", which would give you usage instructions in Linux, killed all processes on the system. Reading this article makes me figure that killa…

That's funny... I almost always try "command --help" first if I'm not sure. Of course some may point out "man command" but I always find man painful, and revert to google.

I think I might have done that too, but I can't remember. This was quite a few years ago.

Re: fork() can fail

#275

Post by Alupis »

jwr wrote: post #247
Alupis wrote: post #57

Earlier quoted context omitted.

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?

? not at all -- you make the deletion of the directory dependent on whether or not you tested true for the directory being present. I don't see why this would cause any race condition...

Re: fork() can fail

#276

Post by Alupis »

ajkjk wrote: post #176
Alupis wrote: post #131

Earlier quoted context omitted.

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…

There'd be far fewer bugs if everyone knew exactly how everything else works. This kind of mistake is godawful and should not be defended. (but it's correctly fixed through stronger typing, not through choosing -48585 as the code for killing everything).

> not through choosing -48585 as the code for killing everything)

Actually, only -1 is the code that "kills everything"

> There'd be far fewer bugs if everyone knew exactly how everything else works.

Perhaps I misinterpreted your meaning, because you seem to be advocating using programming and scripting languages without actually bothering to learn them. Of course this can, will and does lead to very bad effects.

The bottom line is, if you are going to use a function in your program/script -- please, read the docs and understand what is will return at the very least.

Re: fork() can fail

#277

Post by baruch »

danieltillett wrote: post #256
baruch wrote: post #233

Earlier quoted context omitted.

If you care about such things the normal method is to have a backup ssh running on a different port with realtime priority , it is not used at any other time except when some process had gone runaway and you can't do anything else.

I haven't seen this in action. Do you know of a write up describing this?

No write up that I know of. I used it in systems I've made in the past. Some of our services were running in a realtime priority and we needed a way to take care of such a system mostly in development.

Re: fork() can fail

#278

Post by mbel »

masklinn wrote: post #239
MichaelGG wrote: post #200

Earlier quoted context omitted.

Yeah, better than returning a tuple, it should return a sum type. Then you would need to deconstruct it, like how people suggest using a switch: match fork() -> | Error(errno) -> ... | Pid(pid) -> ... Or a general "Choice" sum, perhaps using phantom types so int isn't compatible with int . But then all of a sudden, instead of a single word being returned, a tag and possibly variably-sized result has to be returned, a…

A "Choice" (Either in Haskell, Result in Rust) wouldn't work for fork() as it can have 3 results, and you'd want the `Child` case cleanly and easily separated from `Pid`.

I think the parent meant only a sum type, not a concrete example of it such as Either of Haskell, which would surely not suffice here. In Haskell you would probably define a new sum type for this occasion, e.g.:

    data ForkResult = Failure | Parent Int | Child

Re: fork() can fail

#279

Post by dllthomas »

mnw21cam wrote: post #261
dllthomas wrote: post #80

Earlier quoted context omitted.

I wonder if it would be worthwhile to forego the notion of a CWD for processes entirely.

CWD is a useful concept. If I run gimp in a particular directory, I'd like it to show that directory in the file dialogue when I try to load or save an image. What is evil is a program changing its working directory. That's when it becomes an evil global variable, rather than a non-evil global constant.

Why limit that to one directory? As I expanded on a bit in my response to ygra, I don't mean eliminating any notion of carrying a directory, just that I don't know that there is actually good reason to privilege one particular path universally.

I agree that treating cwd as a global constant solves most (at least) of the issues, I'm just poking assumptions to see what ideas arise.

Re: fork() can fail

#280

Post by dllthomas »

rwallace wrote: post #218
Alupis wrote: post #131

Earlier quoted context omitted.

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?

"Is there a reason fork can't be changed to just crash the program on failure?"

YES. Situation: fork bomb, can't create new processes. How do you notice? Typically because you can't spawn new processes from your shell because fork is failing. With bash, there is a kill builtin - so you have a chance of cleaning things up (depending) if you have a shell open. If the failed fork kills the shell, then oops, you don't have a shell open.

Post reply on HN