Greetings

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?

thanks for feedback

Try to use `nohup setsid process` or daemonize

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:
e.g.

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.

thanks jlightner for the nice elaboration !

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 !

try for example : ping domain.com > test &

How can one explain this incident?

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.

OH! so I've been introducing backgrounding into my code without knowing about it?
actually , a simplified template of the code I'm using would look just like this:
basically straight forward C/C++ code , so why are my programs behaving differently than others regarding the SIGHUP ?

and thanks

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

appreciating the infos

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.

ps -ef to see what is going on.