Linux - ServerThis forum is for the discussion of Linux Software used in a server related context.
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.
well I'm turning to you ..again , because I've a question regarding a custom daemon proggie I'm making , it runs on a shell account , listens for incoming connections and processes certain data etc..
the point is that I'm lil bit confused on whether just running the process in the background then log out or If I should run it in conjunction with nohup ?
plus , would a program that usually prints data out on the screen be making trouble to the systems in general if the session (on which it's running) is logged out?
nohup and backgrounding while often used in tandem are not the same thing (or different ways of doing the same thing).
If you put a job in the background by adding the ampersand "&" to end of line it will die when you exit the shell you started it in because it will send a SIGHUP (hangup signal) to all children including the backgrounded ones.
The purpose of nohup is to insure the process that you're running does NOT die when it receives a SIGHUP (hangup). It ignores SIGHUP.
Therefore you would want to do BOTH nohup and backgrounding if you intend to exit the session that started it:
nohup <program> &
As to your other question. By default nohup will send screen information (stdout a/k/a Standard Out or File Descriptor 1) to a file called nohup.out in the directory where you started. So no it's not normally a problem.
Note: A problem WOULD be experienced only if it stopped and prompted for a response. (e.g. Are you sure you want to proceed? Y/N). Since it isn't going to a terminal it would put that prompt in your nohup.out but you'd have no way to answer it.
Since nohup.out can be overwritten by any process started with nohup it is sometimes preferable to redirect to a file of your own choosing rather than nohup.out. You can do this by using shell redirections:
nohup ls >ls.test 2>&1 &
This tells it to send the stdout (> = 1> with 1 being stdout) to ls.test. It then says to send stderr (a/k/a Standard Error or File Descriptor 2) to the same place as file descriptor 1 (stdout) which is ls.test. Note the ampersand in "2>&1" is special syntax for redirection. It is the other ampersand at the end of the line that backgrounds the entire line.
actually what happens when I background a process then log out is that , the session stops responding where it neither exists nor stays , Nonetheles the daemon keeps running which i can check by connecting to it via internet sockets. etc
and even if I close the terminal window and severe my connection then reconnect to the cyberspace , then I find the program to my surprise still running even that it should have died since I logged out !
Some binaries/utilities have built in "backgrounding". Daemons usually do because they are intended to run as daemons.
By the way if you truly had an interactive session that you wanted to allow to run and interact with later you could use the "screen" utility. This backgrounds your entire session then lets your foreground see it. When you close the terminal (not exit - exit tells it to exit scree) the screen session is still running in the background and you can later reattach to it from the same or another terminal session.
Didn't realize you were writing your own. I'm not really a C/C++ developer though I've had training in them in the past. My responses were dealing mainly with how the shell acts.
I believe for your own code you actually have to define (or at least include the files that define) signals and how to react to them. (You can modify how the shell deals with signals with the trap command.) You might want to have a look at "man signal" which talks about signal.h header file.
OK , now things have gotten much clearer than before!
that's really fantastic that one can tell the program how to act when signals arrive from the kernel , if that has beeen handled properly then there wouldn't be a need for nohup any more
nohup gives you options. Usually you WANT the program to terminate when you close the window.
A simple example: What if you have users running something like "top" that continually measures and outputs information to a terminal? If the terminal suddenly loses power that process would keep running if it ignored SIGHUP even though there is no way to reattach to it or ever see its output. Due to this it is continuing to eat up CPU time and memory. Then the user logs back in and starts top again. That one is now eating up resources. Imagine if all programs were like top and you had dozens or hundreds of users lose power (but of course had your server's power protected). When they all logged back in the system would end up doing double the load (or worse due to attempting to access resources already in use).
It is mostly daemons that you want to always run. Sometimes you have other reasons to make things continue running even though they weren't originally designed that way. For example a shell script that you know is going to take hours to run but you intend to shutdown your desktop (such as a laptop that you ssh'd in from) so you can go home.
>>> ...then I find the program to my surprise still running even that it should have died since I logged out !
NOHUP puts the PPID to 1. So, unless that gets killed it will keep running.
Now if you did not NOHUP but just backgrounded with & the PPID is related to the shell, so just closing that shell will do it (unless it has mechanism of its own).
The logout works by killing the children and parent from the parent down. So, if you start another login that will not get killed if it is not associated with the current login, association is via the PPID PID chain.