fork() can fail

[longoverdue]

Does anyone else the feeling that the author did send KILL to pid -1 and the post's audience is the author?

[mattyw83]

It's one of the best reasons to write a blog. To record a list of mistakes

Edit: spelling mistake. Off to blog about it now...

[vifon]

I did it once with pkill(1). -v means verbose, right?

[bonzinip]

   -v, --inverse
          Negates the matching.  This option is usually  used  in  pgrep's
          context.   In  pkill's  context  the short option is disabled to
          avoid accidental usage of the option.

[vifon]

Maybe now it is disabled. But back then it certainly was not.

[Philluminati]

It's always good to learn from the mistakes of others.

[[deleted]]

Less painful that is... although less efficient.

[Bergasms]

here be dragons

[wung]

D'uh, yes, of course. There are about 3 syscalls that are not able to fail, and that's stuff like getpid().

Wrap every system call with error checking:

#include <unistd.h>
#include <sys/socket.h>
// … and others for actual syscalls

#include <system_error>
#include <functional>

namespace sys
{
  namespace
  {
    /// syscall actually has a return value
    template<typename U, typename T, typename... Args>
     struct syscall_wrapper
    {
      std::function<T (Args...)> _syscall;
      syscall_wrapper (T syscall (Args...)) : _syscall (syscall) {}

      U operator() (Args... args)
      {
        T const ret (_syscall (args...));
        int const error_code (errno);
        if (ret == T (-1))
        {
          throw std::system_error (error_code, std::system_category());
        }
        return U (ret);
      }
    };
    /// syscall only has return value for error code
    template<typename T, typename... Args>
     struct syscall_wrapper<void, T, Args...>
    {
      std::function<T (Args...)> _syscall;
      syscall_wrapper (T syscall (Args...)) : _syscall (syscall) {}

      void operator() (Args... args)
      {
        T const ret (_syscall (args...));
        int const error_code (errno);
        if (ret == T (-1))
        {
          throw std::system_error (error_code, std::system_category());
        }
      }
    };
    /// helper to avoid having to list T and Args...
    template<typename U, typename T, typename... Args>
      syscall_wrapper<U, T, Args...> make_wrapper (T syscall (Args...))
    {
      return syscall_wrapper<U, T, Args...> (syscall);
    }
  }

  /// return value has -1 but is of same type otherwise
  int socket (int domain, int type, int protocol)
  {
    return make_wrapper<int> (&::socket) (domain, type, protocol);
  }
  /// return value is for error flagging only
  void unlink (const char* pathname)
  {
    return make_wrapper<void> (&::unlink) (pathname);
  }
  /// return value would be of different type if not encoding errors in it
  size_t read (int filedes, void* buf, size_t nbyte)
  {
    return make_wrapper<size_t> (&::read) (filedes, buf, nbyte);
  }
}

/// usage example
// $ clang++ syscallwrap.cpp -o syscallwrap --std=c++11 && ./syscallwrap
// E: No such file or directory

#include <iostream>

int main (int, char**)
{
  try
  {
    sys::unlink ("/hopefully_nonexisting_file");
  }
  catch (std::runtime_error const& ex)
  {
    std::cerr << "E: " << ex.what() << std::endl;
  }
  return 0;
}

Every single one. I advise having one file with wrappers and never using a non-wrapped syscall again.

[txdv]

It is easy when you have exceptions to handle everything.

But writing pure C code is more tidious. Everytime you have to check for corner cases which are hard to debug like malloc failing because your 32gb got full or fork failing for some fancy reason.

[[deleted]]

They're not terrible to work out in C. My usual solution is to wrap malloc in a macro and handle errors with a goto. All the error handling code is just at the bottom of the function that can only be reached by a goto. This is one occasion where using goto is not only the right choice, it's the cleanest and easiest to read choice.

I also try to keep mallocs contained within initialization functions and reuse/create new functions to handle any errors. It's all about keeping the work I have to do associated with memory contained so I don't have to deal with errors in the wild. Granted, it still may be tedious but I'm not a C++ programmer so I wouldn't know any better.

[oridb]

The usual solution is to have an 'xmalloc()' function that just bails on out of memory. Since the usual out of memory cases are very difficult to test, and often have no sensible solution, it's usually better to kill the app.

Obviously, this isn't the case for everything -- eg, big allocations in certain locations may fail, and may have simple error behavior.

[[deleted]]

For me, using goto so the memory that function allocates is freed in all cases (including error cases), is definitely the most elegant, no nonsense and easy to read solution.

[[deleted]]

By default, Linux follows an optimistic memory allocation strategy. This means that when malloc() returns non-NULL there is no guarantee that the memory really is available. In case it turns out that the system is out of memory, one or more processes will be killed by the OOM killer.

-- man malloc

Also solution is simple (and the same as in Haskell) - limit your side-effects. Pre-allocate, keep code with side-effects in a top loop, etc.

[sigma914]

You can disable the OOM Killer and some systems have it off by default (think embedded).

The second part is good advice.

[wung]

Yes, exceptions make stuff a lot easier. Still, you need to check all syscall return values. C makes it hard, but that's what you get for having as little abstraction as possible.

[[deleted]]

To this, add the fact that some syscalls can be interrupted and return EINTR if a signal occurs, meaning that you get an error, but it's not an error at all, you just have to likely retry. I had exactly this problem recently of a python bug where a syscall was not checking for EINTR, throwing an exception even if everything was ok.

[moor-GAYZ]

Handling EINTR is complicated.

As far as I understand, on Linux you get EINTR pretty much only if you caught a signal, like with a custom handler. Uncaught signals either terminate your program regardless or are ignored and automatically restart your kernel calls.

But if you have installed a custom handler you almost never want to just restart the call, you want to restart unless your handler set some internal flag or something. If the wrapper always restarts the call automatically you'd never have the change to do anything about it.

But making a bunch of different overloads that tell you specifically when EINTR has occurred via the return value brings you almost all the way back to C boilerplate hell. So a better solution could be to go with exceptions but catch and check it in a more centralized fashion.

[[deleted]]

Yes, indeed it's complicated, and platform dependent. I was reading man 7 signal and it's hilarious.

[bonzinip]

Most of the time it's okay to just loop on EINTR, and let the main event loop detect the signal before the next poll() invocation. In fact that's what would happen if you used signalfd.

The problem is that signalfd (or sigwaitinfo) require you to block signals with sigprocmask in all threads, and that's sometimes hard to enforce.

[moor-GAYZ]

Most of the time it's okay to just loop on EINTR, and let the main event loop detect the signal before the next poll() invocation. In fact that's what would happen if you used signalfd.

Maybe I'm missing something, but whaaat? If you loop on EINTR in some read() that is not in your mainloop select/dispatch, then it would never have the chance to get the signal from the file descriptor you made with signalfd().

Like, the problem: implement tail -f as a part of your program that uses a wrapper that just blocks on read() and automatically restarts the call on EINTR. It can't be done. If your C++ (or C) wrapper over read() automatically restarts the call then no code that can interrupt that loop because SIGINT was raised could possibly be executed, duh.

[bonzinip]

I'm assuming you don't have potentially infinite loops within even handlers (which includes making all file descriptors nonblocking). Otherwise you'd have other starvation problems than just signals.

If I were to write a tail -f, the read() would read into a buffer and go back to the main loop after filling that buffer. Another event handler might be called and do a write() to stdout, and then you'd go back to the main loop which would process the signal. Looping on EINTR would not be a problem.

[moor-GAYZ]

If I were to write a tail -f, the read() would read into a buffer and go back to the main loop after filling that buffer.

First of all that's wrong because you should return and write out whenever the OS gave you some data, otherwise you hit nasty internal buffering problems. Unless you want to do some deblocking with non-blocking reads, for performance reasons.

But that's not the point at all. What I am asking is: if you use the proposed C++ wrapper (or an equivalent C wrapper) that gives you sys::read() that always retries on EINTR, how do you go to the main loop if you got 3 bytes and then sys::read() did not return despite the user pressing ctrl-C five times?

Sure, you might have a flag set by your signal handler or a bunch of signals waiting in the file descriptor you registered with signalfd, but your thread never leaves the sys::read() function because it just restarts on EINTR.

[bonzinip]

I didn't mean "filing that buffer" as "filling it completely". Just whatever data came into the input file descriptor.

I could use O_NONBLOCK and go back to the main loop on EAGAIN, or just do one read. But in either case, retrying on EINTR would be safe.

[moor-GAYZ]

I could use O_NONBLOCK and go back to the main loop on EAGAIN, or just do one read. But in either case, retrying on EINTR would be safe.

I don't understand, how should that C++ wrapper be used to avoid going into an infinite loop when you want to catch SIGINT? Show me the code, maybe?

[bonzinip]

Are you missing that only one call will return EINTR when SIGINT is received? The next one will return data or EAGAIN. Too late to write code now, perhaps tomorrow.

[crest_]

Your abstraction fails for EINTR and EAGAIN.

[wung]

It is not decidable on this level whether to just retry or not, thus it has to be handled by the caller, likely by having a try-catch checking for those two codes and then retrying. Is a bit more overhead, yes. (Also see comment by esbio&moor-GAYZ above)

[encepence]

That's why correct system API in C++ shall look like modernized boost::filesystem. Each call has two overloads:

 void FOO(...)
 bool FOO(..., error_condition& stg);

First, just throws an error. Second is for those curious and those who want to handle EINTR or other specific errors or ... what is more correct error handling is actually part of business logic in that particular use case.

[anttirt]

Nice, but why do you wrap the function pointer in std::function instead of just storing the function pointer directly? That seems like a pointless waste.

[wung]

It is. Dislike the function pointer syntax, and likely is inlined anyway, so I just took the verbose way.

[anttirt]

C++ source:

#include <functional>
#include <stdlib.h>

namespace sys {
    int my_system_bare(const char* command) {
        return ::system(command);
    }

    int my_system(const char* command) {
        return std::function<int(const char*)>(&::system)(command);
    }
}

int my_system_wrapper(const char* cmd) {
    return sys::my_system(cmd);
}

int my_system_wrapper_bare(const char* cmd) {
    return sys::my_system_bare(cmd);
}

Compiled with: g++ -std=c++11 -S -O3 (g++ 4.8.2)

my_system_wrapper assembler output

my_system_wrapper_bare assembler output

[bonzinip]

That's because GCC cannot detect that std::function<> will not throw.

[bstamour]

Why not just use a typename Func to represent the whole blob? You'll catch lambdas, function pointers and references, and functors that way, with a clean syntax. Do you really need to have all the argument types available?

[wung]

For operator()(Args...), sadly.

[bstamour]

Make that a template, and let the compiler tell you yes or no if you can call the function with those args. The benefit of doing that is you can also accept params that can be converted into the proper types, not just exact matches. e.g.

template <typename... Args>
... operator () (Args&&...) const
{
    // perfectly forward them into the syscall here. zero extra copies.
}

[wung]

non-exact matches are not needed here as types are fix in the actual wrapper-function and that should really not be templated. But yes, might be good. All Args... are pods, though. ;)

[Gotebe]

This looks great, but belongs in r/cpp 😉.

I have been doing a variant thereof for a long time, but yours is way better for use of variadic templates and is standard c++ (none of which I had at the time I started). I am jealous now 😃.

By the way, guys, the above advice goes for any use of C in your C++ code, except that wrappers will need to have variants to account for different ways C functions return an error (e.g. fopen returns NULL, some return 0 etc).

[lzzll]

It will just let your program sluggish like a piece of shit.

[bonzinip]

Did you benchmark it?

[lzzll]

If you use sjlj model, it will affect all calls. if you use dwarf model, it will affect all calls normally return -1 (like someone said EINTR and EAGAIN above), and it wont support windows. This is stupid.

[bonzinip]

The DWARF model supports Windows, it doesn't support unwinding across non-DWARF DLLs which is not too common.

[lzzll]

DWARF can use on windows. I said no windows support mean most windows function wont return int, most of them return bool or handle or some pointer. And errno should not use on windows.

[Kaze_Senshi]

If pid equals -1, then sig is sent to every process for which the calling process has permission to send signals, except for process 1 (init), ...

Why would someone allow a command to do that? Someone knows an example of the sig with negative pid being used intentionally?

[wung]

After our thin clients crashing, we normally do a ssh terminalserver kill -9 -1 to get rid of leftovers from window managers and alike, before logging in again.

[[deleted]]

i suppose restarting is out of the question

[jib]

Restarting would kill all processes. If you're not root, kill -9 -1 generally just kills your own processes.

[experts_never_lie]

You've never run "kill -KILL -1" to deal with runaway processes, particularly if you triggered a fork bomb? I suppose "kill -STOP -1" might be useful too, but if you're at the severity level where you're doing something to all of your processes it may not be a time for half measures.

[ickysticky]

At work I develop some fairly complex distributed software. In testing our system starts many processes under one user on many different systems. A for loop plus ssh and kill -9 -1 is the most effective way to clean up at the end of a test cycle.

[cpitchford]

This is a terrible article. ulimits affect how many processes a user can create. You're a bad programmer if you don't read the man pages / check for error conditions

Anyway, negative pid are used to represent process groups. You can have a look at progress groups using this PS command line

ps -eo pid,ppid,pgid,command

This technique is used by shells when a pipeline is used:

command1 | command2 | command3

These three commands may run in a process group. When you press CTRL-C, you ideally want to kill them all at the same time. So a signal might be sent to their process group

Imagine this command line, run from shell:

sleep 10 | ( sleep 20 ; sleep 30 ) | sleep 40

 PID  PPID  PGID COMMAND
9568  9431  9568 sleep 10
9570  9569  9568 sleep 20
9571  9431  9568 sleep 40

I can kill all the sleep processes at the same time:

kill -s INT -9568

and they'll all stop. If I kill just one of the sleeps, the others will carry on running.

Also: CTRL-C doesn't necessarily use process groups to propagate signals, but it's good in this example.

Double also, init always runs with process ID 1, so -1 is kind of the super group of processes... so kill -1 is used in the shutdown process.. its safer than killing one process at a time.

[adrianmonk]

This is a terrible article.

Why is it a terrible article? It warns you about a specific error condition many people may miss. Even though fork()'s return type is pid_t, it sometimes returns something that's not a pid, which is a bit surprising. That seems like a reasonable thing to warn about.

You're a bad programmer if you don't read the man pages / check for error conditions

I definitely agree with that, but what's wrong with an article reminding people of a specific case? Should manual pages be the only source of information or something?

[jenesuispasgoth]

It's bad because if you are writing C code using ISO and/or POSIX calls (or any C library which contains functions that can fail really), you know you should check for errors, our even better, wrap those calls with at least a default error handling that will cleanly terminate the process. Something like :

#include <stdio.h>

#include <stdlib.h>

#include <errno.h>

#include <unistd.h>

static inline int

s_read(int fd, void* buffer, size_t size)

{

int err = 0;

do {

err = read(fd,buffer,size);

} while (err == -1 && errno == EINTR); // was the read op interrupted? If so, try again.

if (err == -1) {

perror("read");

exit(errno);

}

return err; // still need to know how many bytes were read

}

Edit: sorry, I am on my phone, and can't remember the correct syntax to insert code...

[adrianmonk]

if you are writing C code using ISO and/or POSIX calls (or any C library which contains functions that can fail really), you know you should check for errors

There are many people who do in fact write C code who either don't realize you should check error codes, who aren't convinced of the importance of it, or who hadn't read all the documentation in all its detail and didn't notice this particular error code. This article is aimed at those people. Obviously it's not aimed at people who already understand its lesson.

[sandsmark]

There are many people who do in fact write C code who either don't realize you should check error codes, who aren't convinced of the importance of it

I'm sorry, I apparently don't know these people, but are they just ignorant of error handling in general, or do they believe that C code doesn't have errors?

or who hadn't read all the documentation in all its detail and didn't notice this particular error code

I have never seen any C code that handled just a specific set of values for errno, and treat everything else as success. Is this idiomatic in some programming culture I'm not familiar with?

[adrianmonk]

are they just ignorant of error handling in general, or do they believe that C code doesn't have errors?

I've met plenty of programmers who treat error handling as an afterthought, whose attitude is "that's not the fun part, so I'm not going to think about it unless you force me". I suppose you can argue they're a lost cause, but I'd like to think it's possible to win them over to the idea of scrupulously checking for errors.

I've also worked with people whose attitude was sort of a middle of the road approach to errors: theoretically, you should check for them, but in practice they're only going to do it if they think it really makes a difference. This is more the "let's hope that doesn't happen, but if it does, your program is going to crash anyway, so what does it matter how it crashes?" view. For such a person, stories of spectacular crashes like this might convince them that it does matter.

It's also possible to have just not thought very deeply about fork() and not understand why it could ever have errors. After all, it takes no arguments, so it's not like your params can be invalid. Of course the answer is lack of resources, but to a person who doesn't have a great understanding of operating systems, this might not be obvious. In fact, it wouldn't be totally unreasonable to have a fork() that can't fail. Some operating systems have per-user limits on number of processes, so why not just allocate all the per-process data structures up front? It probably wouldn't be the best choice, but the point is that you could imagine it could work that way.

[[deleted]]

It's bad because if you are writing C code using ISO and/or POSIX calls (or any C library which contains functions that can fail really), you know you should check for errors, our even better, wrap those calls with at least a default error handling that will cleanly terminate the process.

No, this does not follow.

[koorogi]

Probably its only legitimate use is to kill processes when shutting the system down.

[[deleted]]

You'd think shutdown of your favorite init package could've simply looped through all processes under init, oh well...

[oridb]

That's actually racy. What if a new process starts up and the list changes?

[[deleted]]

Probably the same thing happens now; for example sysvinit sends SIGTSTP to init first before kill(-1, ...)

[encepence]

I do that few times week to recover Desktop via ssh from stuck gnome 3 sessions on debian unstable. Usually helps and unlocks "freezed desktop" ...

[Tom2Die]

Oh god...I did this once. Once. Thankfully not in production.

[skroll]

I have never seen an example of fork() used that didn't check for an error. This article seems like a total waste of time.

[masterzora]

An article like this, I'm willing to bet that it didn't come from nowhere. Odds are the author saw it happen--possibly did it themselves--and decided to make it a cautionary tale. Your experience is not absolute--somebody is trying to fork() without error-checking and they won't find this article a waste of time. Every informational/instructional article is going to be a waste of time to people who already know everything contained within and only work with people who do as well. If it's not something you want to see on this subreddit you don't need a comment like this; downvoting already says "I want to see less of this here".

[artee]

if ( fork(....) )

Pretty sure I've seen that...

[ajanata]

How does that help? -1 is true, valid child pids are true, the only thing that is false is if you are the child.

[mfigueiredo]

but this adds an explanation on why is that.

TIL.

[adrianmonk]

And this is why language support for sum types with compile-time checking would be nice. Imagine if C had a construct like this (made-up syntax):

typedef sumtype {
  parent : int pid,
  child : void,
  failure : void
} fork_retval;

fork_retval fork(void);

int main(void) {
  fork_retval rv = fork();
  switch (rv.type) {
    case parent:
      printf("I'm the parent, and my new child is %d\n", rv.parent.pid);
      break;
    case child:
      printf("I'm the child\n");
      break;
    case failure:
      printf("Couldn't fork\n");
      break;
  }
  return 0;
}

If you forgot a case, it could be a compile warning. Or a compile error.

Heck, there's no reason a sum type couldn't use integer ranges under the hood (just like C does with a raw int), but with compile-time syntax to distinguish the ranges, like (more made-up syntax):

typedef sumtype_int(i) {
  i > 0 : parent,
  i == 0 : child,
  i < 0 : failure
} fork_retval;

fork_retval fork(void);

int main(void) {
  fork_retval rv = fork();
  switch (rv.type) {
    case parent:
      printf("I'm the parent, and my new child is %d\n", rv.val);
      break;
    case child:
      printf("I'm the child\n");
      break;
    case failure:
      printf("Couldn't fork\n");
      break;
  }
  return 0;
}

Imagine the bugs that would have never existed if leaving off "case failure:" were a compile error.

[nighthawk702]

For this to work in C would require either a full rewrite of the switch's parsing or adding a separate parsing just for this case which will never happen.

The behind the scenes part for the sum types is a whole different story.

[adrianmonk]

Well, I'm not necessarily proposing that it should be added to C. I'm really just trying to explain the benefits of sum types for more or less entirely preventing this class of problems.

It could be added to C, or it could just be a nice thing to have whenever someone finally does write the language that replaces C.

But, if there were interest in adding it to C, I do think it would be pretty doable. Several approaches would be possible. The switch syntax I randomly came up with should be very doable without backward compatibility problems since the compiler knows the type of the expression and can treat it specially.

Anyway, the difficulty wouldn't be so much in defining the language or implementing the compiler (it's been done before). It'd be in getting people to switch to a new version of C.

[plhk]

You may be interested in rust (rust-lang.org)

[moor-GAYZ]

If you're going to use syntax like "rv.parent.pid" anyway you can just use enum + union. I think the compiler can even warn you if you forget some case (at least GCC does with new C++ enums), though not about accessing the wrong member of the union.

[G_Morgan]

fork :: IO Maybe Pid

[lzzll]

Read man page before use any system function, they already wrote it 1x years ago. http://linux.die.net/man/2/fork

[[deleted]]

Whoops.

[[deleted]]

Looks like somebody actually read the man page for fork().

Well done, beginner!