Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 6 years ago.
Improve this question
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)
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.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 4 years ago.
Improve this question
I know that pthread_kill requires Signal as a parameter but I am just curious about that what will be happen if I will give 0 as a signal (no SIGUSR1 or any other) .
Thread will be still killed in above situation ?
I am trying to learn these stuffs I am putting my hands in threading in C.
It will happen exactly what is described in the man page :
If sig is 0, then no signal is sent, but error checking is still performed.
That means it will act like pthread_kill has send the signal, but without sending it. It's usefull when you try to check wether a particular PID respond to signal or not. It's a "dry-run".
Edit : Well, out of habit I've writted "PID", but it's more the "TreadId" than any other things.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
man for int kill(pid_t pid, int sig); says:
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), but see below.
Does this mean that if my program is run with root permissions and it accidentally (due to memory corruption or a hack) provides -1 as pid argument - this will cause a complete DoS for the entire system?
If so, is it recommended to always perform a double check for the pid argument value before calling this potentially disasterous call? (just sayin')
Does this mean that if my program is run with root permissions and it
accidentally (due to memory corruption or a hack) provides -1 as pid
argument - this will cause a complete DoS for the entire system?
Yes, such a scenario is possible. But the chances of it happening is very less. Because no program that run with root permissions would do such a thing. If a malicious user/binary has somehow got gained root privilege, then sending signals is just one of the problems.
If so, is it recommended to always perform a double check for the pid
argument value before calling this potentially disastrous call?
That's just super paranoid thinking. There are thousands of ways to do disastrous activities.You might as well worry about:
What if there's not malicious daemon, ran at system startup, does:
kill(-1, SIGKILL);
How do you know if library function you make wouldn't call reboot(2) and reboot your system?
etc.
Besides, PIDs are not just user provided values that need to be sanitized. PIDs are mostly values acquired within the program using system calls or library calls. So the chances of "accidentally" using -1 is zero. Basically, you someone/program has root privilege and decided to screw your system then there's not much you can do.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 7 years ago.
Improve this question
I am building a very tiny shell in c,
I have the option on running programs in the background.
I keep a list of all my jobs meaning all the ones in the bg.
Now if i want to go and update this list, how can i check is a process is finished or if its still running.
ps
if i waited with waitpid for some process, will i still be able to check if the process is done? (i mean if i used waitpid it took the process of zombie state.
You should be able to call waitpid, passing it the process id and the WNOHANG option and call the WIFEXITED macro on the integer returned through status argument. See Just check status process in c.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
What is a practical relevance of signals in C programs ?
Where do we need signals. I am getting confused and feeling traped in this topic, Who generates signals ?
Signals are a lightweight way for processes to communicate with each other asynchronously; as such, it shouldn't be a surprise that processes generate signals.
Signals are in C because signals were how you communicated with a process in the original version of UNIX.
They are a fairly simple way of allowing your process to respond to external requests such as "re-read my config file", for example.
The K&R chapter is a good intro, but read the C standard to see the minimum for what is defined. In particular, the only portable thing you can do in a signal handler is either abort the process, or set an atomic flag which your main thread of execution will check in due course. In practice, people do more complicated things in signal handlers such as making system calls.
Signals provide a way of supporting asynchronous interrupts in a C program. That said, the C spec is almost completely void of specified behavior for signals, leaving them essentially entirely up to the implementation, so writing portable code that uses signals is almost impossible. You need to carefully read the documentation for your implementation to see what exactly signals can do.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
I am trying to add instrumentation into my code that will print out something like
'Thread 1 forks Thread 2'
Any suggestions on how I can achieve this?
Terminology correction: one thread may create another thread, not fork, which is usually
used to mention one process forking another.
No, a thread has no way to get another thread's identifier. On Linux, you can check if gettid() == getpid() to find if it's the main thread. Solaris has thr_main() to identify if the caller is main thread or not. FreeBSD has pthread_main_np() for the same purpose.
But there's no way to identify parent-child relationship between any threads. Any thread can create more threads. You'll have to use pass the thread identifiers around when creating threads or use global data structure to maintain this information.