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.
I.e., what causes it? I'll make myself more clear. I have the program lazy, a CD player, which uses two signals (I'm reading the sources): SIGINT and SIGQUIT. The manual does not say a word about, for example, using ^C to stop the program.
However, while playing a CD, I sometimes want to halt the program before the cd ends playing and press ^C. What happens is simply that the program jumps to the following track. A new ^C jumps to the next one, and so on until the last the lead-out area is reached and the program stops.
Question: Why then these two signals in the sources. Can it be a bug?
EDIT: I have just discovered a wonderful thing. ^C does what I said and, ^| stops execution. However, I do not understand. Wikipedia says SIGQUIT does a memory dump?!
As Catkin says, there is a conventional expected response for most signals, see his links.
SIGUSR1 & SIGUSR2 are 'undefined' ie designed to be used only by the specified trap code in the specific program.
In theory you can trap just about all of them and change the effect, but this can lead to confusion as you can imagine, so its rarely done.
SIGHUP is one that tends to be altered because HUP refers to the old dialup days and is rarely used for that these days.
Its frequently used to tell a prog eg apache to re-read its cfg file.
SIGKILL (signal num 9) is usually enforced by the OS no matter what; useful for killing a wedged/stuck/hung program that won't respond to the usual signals.
Note that this kills the process immediately(!) WITHOUT allowing it to shutdown cleanly eg close open files. This may well result in file corruptions; try to avoid this signal if possible.
Late in the shutdown process, the shutdown scripts send all remaining processes the SIGTERM signal. The idea is that any processes that have not already been shut down by the shutdown scripts should shut down themselves. A few seconds later the shutdown scripts send all remaining processes the SIGKILL signal which kills them immediately. Thus, although a programmer could program to ignore SIGTERM, the sane choice is to program to clean up and exit on receipt of SIGTERM.
Kind of you. I had begun to learn about interprocess communication but some distract me afterwards. I think it was the famous shell scripting, that I'm always beginning from scratch, although I have plenty of books.
Now, with the first serious program in C I am writing, I feel more in my land. And am being forced to learn about things which matters me more than scripts. Cheers.