2

As we know that exec family function calls eventually calls execve() which is a system call and remaining are library functions. So, typically, whatever implications applies on execve() are true for other exec*() functions as well.

I would like to know if, during execution of execve(), all signals are blocked until it succeed, or if there is a way to pass signal to that pid which corresponds to exec? (I know it does not return on success and further execution of calling function does not happen)

perror
  • 7,071
  • 16
  • 58
  • 85
theartist33
  • 470
  • 1
  • 6
  • 13
  • 2
    Unsure what you're asking for; can you provide some pseudo-code to illustrate what you're asking? – csl May 23 '16 at 18:13
  • @csl my question is simple and straight forward , does execve (or any exec function ) blocks all signal until it finishes ? – theartist33 May 23 '16 at 18:20
  • See http://unix.stackexchange.com/questions/16455/interruption-of-system-calls-when-a-signal-is-caught – csl May 23 '16 at 18:26

1 Answers1

4

I am not sure I got your question right, so feel free to correct me if I am wrong.

But, basically, yes, system calls can be considered as 'atomic' from the process point of view. So, once the execve() system call is started, only the kernel has the hand on it and it won't release the process until running the new command or failing with an error code or raise the SIGKILL signal (as SIGKILL is the only unblockable signal).

But, once the execve() spawned a new process (and returned from the kernel), it is perfectly interruptible with any signal.

perror
  • 7,071
  • 16
  • 58
  • 85
  • my question is simple and straight forward , does execve (or any exec function ) blocks all signal until it finishes ? – theartist33 May 23 '16 at 18:21
  • Yes. Because it lies in kernel-space (not in user-space). – perror May 23 '16 at 18:22
  • so how to end up/kill exec function which is stuck(hung) without killing it's process id from some other context ? – theartist33 May 23 '16 at 18:41
  • A process will be very unlikely stuck in kernel-land when started... So, if it is hanging is probably once the program has been started, and you should be able to kill it with a `SIGKILL` as any other process. – perror May 23 '16 at 19:28
  • for e.g. , process like bdf (in hpux or df in linux) doesnt timeout until it finshes its output. Now if there is any nfs file system which is not responding ( nfs server) then bdf gets hung and never timeout when it tries to reachout nfs server which is not responding hence to kill it you can kill the process of bdf from another terminal (command line). I was trying to run bdf from C program and passing signal ( alarm ) which will terminate after n seconds( n being argument to alarm function) but since alarm sends SIGALRM which gets blocked until bdf ( through exec) completes. – theartist33 May 23 '16 at 21:37
  • Okay, but the case you are describing is very special because the kernel is waiting for a resource (that is possible not responding). This is probably the unique possibility of unkillable process in the UNIX World. See [this question](http://stackoverflow.com/questions/223644/what-is-an-uninterruptable-process) on SO. – perror May 23 '16 at 22:22