Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Check for async-signal-safety #10

Open
elfring opened this issue Nov 22, 2013 · 1 comment
Open

Check for async-signal-safety #10

elfring opened this issue Nov 22, 2013 · 1 comment

Comments

@elfring
Copy link

elfring commented Nov 22, 2013

I see in a source file that functions like "fopen" and "getenv" are used before the function "execvp" will be called. Would you like to improve your program design if you consider information like the following?

... Consequently, to avoid errors, the child process may only execute async-signal-safe operations until such time as one of the exec functions is called. ...
@jsipprell
Copy link

Async signal safety of the type you're talking about only applies to forking when multiple threads of execution are running in the parent prior to fork().

For single threaded processes there are a couple of process signal synchronization issues however:

  1. A race condition where the parent is unable to catch SIGCHLD caused by an immediately premature death of the new child. This is not an issue for daemonize however, as when in parent-mode it does not attempt to monitor the child process status post-fork and uses daemon() (either system-provided or the bundled version) to immediately terminate. ... but that leads to...
  2. The bundled daemon() implementation does not mask SIGHUP prior to forking and calling (in the child) setsid(). This creates a race condition where a grandparent process, often a shell, sends the entire process group SIGHUPwhile it exits immediately after the initial parent daemonize exits. If the child has not successfully completed calling setsid() it will die with the rest of the process group. Obviously, this is only a problem on systems which do not provide daemon() in their libc -- a rare case these days.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants