Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
Without that trap on the TERM signal in the function, there is a race condition that determines whether you see the "terminated" message. If the parent shell exits before it sees the SIGCHLD that the child has exited, then it will not print that message. But, if the child exits first and the parent sees the abnormal return status, then you will get that message. Forcing the child to give a normal return code avoids the issue.
You will see the "terminated" message every time if you put a "sleep 2" in the parent right after the kill.
I think the post by rknickols above suggested putting a
trap "exit 0" TERM
in the top of the blinker function. What that will do is if the TERM signal is fired, leave where you are executing in blinker and do an exit 0. Then the infinite loop of blinker terminates and exits with a 0.
Since the TERM was fired by the kill command, the script then returns to the line below that and continues from there.
You need to recognize that you have two copies of the script executing in separate processes. One is running in the background executing the infinite loop in the blinker() function; the other is in the foreground running the mainline portion of the script. These are scheduled independently. When the mainline process sends the signal to the background process, there are two possibilities for the sequence of operations:
It could be that the mainline process gets interrupted on return from the kill command (which is a shell builtin command, BTW), and the background process next executes, sees the TERM signal, and exits. For that case, when the mainline shell next executes, it will receive a SIGCHLD signal, check the termination status, and print a message if the termination is abnormal.
Alternatively, the mainline process might continue after the kill and exit before the child terminates, leaving the blinker loop running in an orphan process, which would now be adopted by the init process (PID 1). When the background process is next scheduled, it will see the TERM signal and exit. The init process will reap the status of the terminated process (If it didn't, you would have created a zombie.), but will ignore the exit code. Thus, no message.
If you insert the sleep call that I suggested for testing, you ensure that Case 1 occurs.
That was very well explained! I get a bit confused when a new script is spawned by another! I have done different techniques to determine that a child process has finished, but I like the above script.