Tag Archives: handlers

Explicitly ignorant in Unix

I'm working on a patch for antinat, to make it do some cool/weird stuff that it can't do at the moment.

In case you're wondering antinat is a great implementation of a socks server. It supports socks4, socks5 with user/password authentication, accept/reject acls based on user or ip, easy configuration in an XML file and it's also multithreaded ( ok maybe this is not so great for some but I like it ).

I'm not going to write about the patch I'm working on but maybe I'll write about that in another post.

While I was looking over it's source code I found this funny comment right before a function that was used to handle the SIGPIPE signal:

  2. /*
  3. UNIX trivia - when is a problem a problem? When you don't ignore it.
  4. If you do nothing, well, you're not being ignorant enough. You have
  5. to be explicitly ignorant.
  6. */

This is funny but the comment has a good point. If you write an application and it tries to write to a connection that was closed, your program will receive a signal with the code SIGPIPE, which means ( according to the man page of the kill program) that if the proces does not have a default handler for SIGPIPE then it will just exit. So there you have a big problem.

The simple solution is to just set your own signal handler for SIGPIPE . So you have to set a function that will be called when the program receives a SIGPIPE and your function doesn't really have to do anything about it, so it will just ignore it and reset the handler to itself.

  2. void
  3. ignorer (int x)
  4. {
  5. signal (x, ignorer);
  6. }

But if you don't explicitly set this, your process will just die upon receiving a SIGPIPE and you really don't want that especially when writing server applications.