4
int main()
{
    if (!fork()) sleep(3000);
    exit(0);
}

Invoking the program above from the shell yields a orphan process which

  1. is adopted by init or upstart (on my Ubuntu Desktop)
  2. is in the same session as the shell
  3. lost group leader
  4. is not managed by the shell's job control, which means it will not receive SIGHUP even if the shell receive an SIGHUP

About 4: I have tested and confirmed this in bash on my Ubuntu Desktop. Not sure whether this hold true for signals other than SIGHUP. The same applies if you disown a job: process groups that are not listed by jobs command will not receive SIGHUP.

Since we can also close all FDs and chdir, and log to files, the only difference between this and a normal daemonization is that:

  1. my process still shares the same session with the shell
  2. my process still has a "controlling tty", as displayed by ps j

So my problem is: Can we consider this process as a daemon?

Or in other words, why it is so important for a daemon to be in a new session (call setsid()) without ctty, since it doesn't matter anything (correct me if not) for it to be in the same session of the calling shell with ctty connected?

Or in other words again: Why it is bad for a process who wants to serve as a daemon to keep its session unchanged and still connected to a terminal (even if we close its FDs)?

I think these problems are consistent in their nature. Thanks in advance.

References (yet didn't convince me)

SedriX
  • 185
  • 1
    The setsid() question's accepted answer mentions quote from external source: "When a user logs out from a session, all processes associated with that session are killed. For processes that are daemons you do not want this to happen." Your code example will be killed if either session or controlling tty exit, making it non-daemon. At least so is my understanding – Sergiy Kolodyazhnyy May 27 '18 at 08:28
  • Also relevant: https://unix.stackexchange.com/q/240646/85039 – Sergiy Kolodyazhnyy May 27 '18 at 10:27

0 Answers0