4

I wrote a daemon program on Linux according to the guide at http://linux.die.net/man/1/daemonize, but the process crashed several times and I cannot find the reason. It has troubled me for a few days.

Today I happened to have read 'UNIX network Programming volume 1, Third Edition' by W.Richard Stevens. And in this book, it shows an example to write daemon program. After reading the example, I realized 'Disassociate from the control terminal' is missing from my code.

Now my question is to daemonize a process, why we need disassociate from the control terminal? And does it related to the crash of the process? Is there any other place is missing in my code for daemonize?

Appreciate your replies.

Here is my code:

bool daemonize()
{
    // http://linux.die.net/man/1/daemonize

    // change working dir to root
    (void) uchdir("/");

    // close stdin, stderr, stdout
    if (int fdnull = open("/dev/null", O_RDWR))
    {   
        dup2 (fdnull, STDIN_FILENO);
        dup2 (fdnull, STDOUT_FILENO);
        dup2 (fdnull, STDERR_FILENO);
        close(fdnull);
    }   
    else
    {   
        Log (ERR, "Failed to open /dev/null");
        return false;
    }   

    // detach from previous process group
    if (setsid () == -1)      /* request a new session (job control) */
    {   
        Log (ERR, "Failed to detach from previous process group");
        return false;
    }   

    // inhibit others completely and group write
    umask(027);

    // it's dameonized!
    return true;
}
jpihl
  • 7,941
  • 3
  • 37
  • 50
cartman
  • 732
  • 2
  • 8
  • 20
  • 1
    That isn't C. It looks like C++. Fix your tags, please. (We disassociate from the terminal, because when the terminal closes, all processes still connected to the terminal get a SIGHUP signal. A new process group (new session) is started because signals can be sent to an entire process group (and this mechanism is very useful in e.g. notifying multiprocess daemons), and the new daemon is logically separate from previous process group.) Also, Linux processes do not *"crash for no reason"*. There is always a reason: either exit status, or signal that caused the process to die. – Nominal Animal Sep 11 '16 at 14:30
  • 1
    Stop adding C tag for non-C code! – too honest for this site Sep 11 '16 at 14:34
  • 1
    Just changing some calls does not make C++ code C code. That one does no compile with a C compiler! Make up your mind! Use a C compiler to compile C code. C++ is a **different** language! SO you apparently use a C++ compiler to compile this. – too honest for this site Sep 11 '16 at 14:40
  • 1
    That said the language is mostly moot here since the question is about disassociating from a terminal and a crash that will likely be unaffected by e.g. using `0` instead of `false`... What we *really* need is: 1) This to be two separate questions (Why do we detach + Why is this crashing) and 2) A little more debugging effort, e.g. a clearer description of "crash" and a gdb stack trace or something at minimum, and some more context, to solve the latter. – Jason C Sep 11 '16 at 14:48
  • @JasonC: I agree about the language. (just that: `false` is also part of the C language; that's not the problem). – too honest for this site Sep 11 '16 at 14:49
  • @Olaf Yeah... I forget, I haven't used C in a very long time. But... you know what I mean. Just imagine that I gave a correct example instead, heh. – Jason C Sep 11 '16 at 14:51
  • 3
    @Olaf I agree with you it's not C code. But for this daemonize question does it matter if it's written by C or C++? All the system calls I used here are written by C and I want to know if something is missing here. – cartman Sep 11 '16 at 14:57
  • It was not me using wrong tags. If using library functions or system calls written in C would justify the C tag, **every** question had to be tagged C. You hardly can use any system function which does not originate from C source code at some level. – too honest for this site Sep 11 '16 at 15:11
  • Wtf? The "guide" that is linked is a man-page! A man(1) page at that! Who even cares if it runs! You were able to extract a guide for building a c++ server... from the manual for a command-line program? _That_ is the real feat here, my friend! – Nate T Nov 01 '21 at 09:45

3 Answers3

5

The basic steps to deamonize a C or C++ program have already been mentioned in this question: Creating a daemon in Linux

Yes, the question there was for C and not for C++, but since the system calls you need to daemonize a program are C functions in both cases, that really does not make a difference.

Community
  • 1
  • 1
Striezel
  • 3,693
  • 7
  • 23
  • 37
4

I found this github repository useful, it has what you need to build a daemon:

Simple example of daemon for Linux

And here is a stack overflow thread why double fork is nessesary.

Ako
  • 956
  • 1
  • 10
  • 13
0

Not addressing your actual question but…

I wrote a daemon program on Linux according to the guide at [http://linux.die.net/man/1/daemonize][1],

please don't!

Programs that daemon-ize are the bane of any sensible init system and service tracker. The problem is, that after a program detaches from its controlling terminal and parent process it gets difficult to keep track about its state and regain control over it. The usual way of using PID files is prone to race conditions, which is especially bad if the intention is to automatically respawn such a process.

The use of daemon led to the development of several hacks, some outright ugly some kind of okay, but none of them being beautiful. Do yourself and the rest of the world a favour and don't daemonize your program.

datenwolf
  • 159,371
  • 13
  • 185
  • 298
  • 2
    If you're going to play contrarian, provide some concrete evidence that daemonizing is a bad idea. – notlesh Dec 18 '19 at 18:20
  • 1
    @notlesh: The problems with daemonizing processes have been discussed wide and far. The main problem is, that by backgrounding and detaching a process, you're severing the primary communication channel by which a supervisor can observe the health of the service process. The usual methods of communication for detaching daemons are PID files (which are unreliable and prone to race conditions) and sockets, which are nontrivial to get right. Supervisor program developers have to resorts to hacks like https://cr.yp.to/daemontools/fghack.html and https://cr.yp.to/daemontools/pgrphack.html – datenwolf Dec 19 '19 at 08:33
  • 1
    @notlesh: See also https://stackoverflow.com/q/25906020/524368 and https://stackoverflow.com/a/697064/524368 – datenwolf Dec 19 '19 at 08:36