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

31–40 of 320 posts

Re: fork() can fail

#31

Post by schrodinger »

slingerofwheat wrote: post #15
arbitrage wrote: post #4

Earlier quoted context omitted.

Your username is offensive. I'd like to take what you say seriously, and perhaps even engage in further conversation about the topic at hand, but ... you know ... you look stupid. Grow up. You should be embarrassed.

So. You mean you actually DON'T like to take what he said seriously. His username is offensive, but you just also gave it credibility.

"I'd like to" means I would like to, presumably meaning "I would like to take your post seriously, but your offensive handle is preventing me"

Re: fork() can fail

#32

Post by acdha »

Aurel1us wrote: post #10

Just as a reminder: "So, malloc on Linux only fails if there isn’t enough memory for its control structures. It does not fail if there isn’t enough memory to fulfill the request." - http://scvalex.net/posts/6/

That page is incomplete: malloc() will fail on Linux depending on the `vm_overcommit` setting:

https://www.kernel.org/doc/Documentation/vm/overcommit-accou...

Re: fork() can fail

#33

Post by colanderman »

cperciva wrote: post #16
jgrahamc wrote: post #6

Quietly goes to check the last piece of C I wrote containing a fork(): if (daemon && !test_mode) { int pid = fork(); if (pid == -1) { fatal_error("Failed to fork"); } if (pid != 0) { write_pid(pid_file, pid, !test_mode); exit(0); } } else { write_pid(pid_file, getpid(), !test_mode); } Phew!

I usually use switch with fork: if (daemon && !test_mode) { int pid; switch (pid = fork()) { case -1: /* Error */ fatal_error("Failed to fork"); case 0: /* In child */ break; default: /* In parent */ write_pid(pid_file, pid, !test_mode); exit(0); } } else { write_pid(pid_file, getpid(), !test_mode); }

For daemonization, daemon(3) is better (EDIT: assuming you only care about Linux). (It also chdirs to /, closes STD*, and detaches from the terminal.)

Re: fork() can fail

#34

Post by kazinator »

I once did

    rm -rf $PREFIX/usr/lib
in a Bash script being run as root. PREFIX was misspelled, and set -u was not in effect, so the misspelled variable silently expanded to nothing ...

Re: fork() can fail

#35

Post by quotemstr »

I wish posix_spawn were ubiquitous; it's a much better process-launching interface than fork: it's naturally race-free and amenable to use in multi-threaded programs, and unlike fork(2), it plays well with turning VM overcommit off. (If overcommit is off and a large process forks, the system must assume that every COW page could be made process-private and reserve that much memory. Ouch.)

Re: fork() can fail

#36

Post by kazinator »

zxcdw wrote: post #27
zokier wrote: post #13

Who needs type safety when we got integers.

Who even wants that? When I am coding, sure as hell some compiler vendor won't be telling me what to use my bits for! I identify myself as an atypical coder.

If you tell yourself what the bits are for and stick to it, that is still type. Real chaos is when even you don't.

Re: fork() can fail

#37

Post by quotemstr »

Aurel1us wrote: post #10

Just as a reminder: "So, malloc on Linux only fails if there isn’t enough memory for its control structures. It does not fail if there isn’t enough memory to fulfill the request." - http://scvalex.net/posts/6/

Malloc can also fail if you're out of address space without necessarily being out of memory.

NT does a much better job of separating these concepts than Unix-family operating systems do. Conceptually, setting aside a region of your process's address space and guaranteeing that the OS will be able to serve you a given number of pages are completely different operations. I wish more programs would use MAP_NORESERVE when they want the former without the latter. (I'm looking at you, Java.)

One day, perhaps when I am old and frail, we will achieve sanity and turn overcommit off by default. But we're a long way from being able to do that now.

Re: fork() can fail

#38

Post by agwa »

jwise0 wrote: post #28

In a similar family, note also that setuid() can fail! If you try to setuid() to a user that has has reached their ulimit for number of processes, then setuid() will fail, just like fork() would for that user. This is a classic way to get your application exploited. Google did it (at least) twice in Android: once in ADB [1], and once in Zygote [2]. Both resulted in escalation. Check your return values! All of them! […

Thankfully, setuid() no longer fails on Linux because of RLIMIT_NPROC, as of 2011[1].

Still, I agree with you 100%: check your syscall return values, especially security-critical syscalls like setuid!

[1] http://lwn.net/Articles/451985/ and http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.g...

Re: fork() can fail

#39

Post by cperciva »

colanderman wrote: post #33
cperciva wrote: post #16

Earlier quoted context omitted.

I usually use switch with fork: if (daemon && !test_mode) { int pid; switch (pid = fork()) { case -1: /* Error */ fatal_error("Failed to fork"); case 0: /* In child */ break; default: /* In parent */ write_pid(pid_file, pid, !test_mode); exit(0); } } else { write_pid(pid_file, getpid(), !test_mode); }

For daemonization, daemon(3) is better (EDIT: assuming you only care about Linux). (It also chdirs to /, closes STD*, and detaches from the terminal.)

Alas, daemon(3) is not POSIX.

Re: fork() can fail

#40

Post by cliveowen »

cperciva wrote: post #16
jgrahamc wrote: post #6

Quietly goes to check the last piece of C I wrote containing a fork(): if (daemon && !test_mode) { int pid = fork(); if (pid == -1) { fatal_error("Failed to fork"); } if (pid != 0) { write_pid(pid_file, pid, !test_mode); exit(0); } } else { write_pid(pid_file, getpid(), !test_mode); } Phew!

I usually use switch with fork: if (daemon && !test_mode) { int pid; switch (pid = fork()) { case -1: /* Error */ fatal_error("Failed to fork"); case 0: /* In child */ break; default: /* In parent */ write_pid(pid_file, pid, !test_mode); exit(0); } } else { write_pid(pid_file, getpid(), !test_mode); }

You should always put a break statement at the end of a default branch. The default case is put at the end as a convention but no one (certainly not the C standard) prevents you from adding a new case after, which will be promptly executed even though probably it's what you want. I think this is mentioned a best practice in the K&R.
Post reply on HN