3
votes

I am trying to find out a way to launch a custom daemon from my program. The daemon itself is implemented using double-forking mechanism and works fine if launched directly.

So far I have come across various ways to start a daemon:

  1. Create an init script and install it to init.d directory.
  2. Launch the program using start-stop-daemon command.
  3. Create .desktop file and place in one of the autostart paths.

While the 1st 2 methods are known to start the service using command line, the 3rd method is for autostarting the service (or any other application) at user login.

So far my guess is that the program can be executed directly using exec() family of functions, or the 'start-stop-daemon' command can be executed via system() function.

Is there a better way to start/stop service?

1
You are asking for better way; please tell us in what aspects a different way could be better. More portable? Faster execution? Shorter code? More robust against special situations? Other aspects? - Alfe
I am not sure if this is the suggested way to do this. I am new to Linux programming and could not find any reference regarding the suggested method to start daemon programmatically - skaur
I've never heard of a user process starting a system daemon unless it was a system configuration tool or similar. So I guess just calling that start/stop script via exec() is the only intended way of doing it. - Alfe
@Alfe: Thanks for the suggestion. I guess this answers my question. Can you post is as the answer so that I can mark it? - skaur
I've just never heard of it, but I don't think that's a suitable answer ;-) Thank you for offering to accept that, but I think we should leave your question open (unaccepted and unanswered) until someone has something more definitive to say. - Alfe

1 Answers

0
votes

Generally startups are done from shell scripts that would call your C++ program which would then do its double fork. Note that it should also close unneeded file descriptors, use setsid() and possibly setpgid/setpgrp (I can't remember if these apply to Linux too), possibly chdir("/"), etc. There are a number of fairly normal things to do which are described in the Stevens book - for more info see http://software.clapper.org/daemonize/daemonize.html

If the daemon is supposed to run with root or other system user account, then the system /etc/init/ or /etc/init.d/ mechanisms are appropriate places to have scripts to stop|start|status|etc your daemon.

If the deamon is supposed to be for the user, and run under his/her account, you have a couple of options.

1) the .desktop file - I'm not personally a fan, but if it also does something for you on logging out (like let you trigger shutting down your daemon), it might be viable.

2) For console logins, the ~/.bash_login and ~/.bash_logout - you can have these run commands supported by your daemon's wrapper to start it and (later) shut it down. The latter can be done by saving the PID in a file or having the .bash_login keep it in a variable the .bash_logout will use later. This may involve some tweaking to make sure the two scripts get run, once each, by the outermost login shell only (normal .bashrc stuff stays in the .bashrc, and .bash_login would need to read it in for the login shell before starting the daemon, so the PATH and so on would be set up by then).

3) For graphic environments, you'd need to find the wrapper script from which things like your X window manager are run. I'm using lightdm, and at some point /etc/X11/Xsession.d/40x11-common_xsessionrc ends up running my ~/.xsessionrc which gives me a hook to startup anything I want (I have it run my ~/.xinitrc which runs my window manager and everything), as well as the place to shot everything down later. The lack of standardization for giving control to the user makes finding the hook pretty annoying, since just using a different login manager (e.g. lightdm versus gdb) can change where the hook is.

4) A completely different approach is to just have the user's crontab start up the daemon. Run "man 5 crontab" and look for the special @reboot option to have tasks run at boot. I haven't used it myself - there's a chance it's root restricted, but it's easy to test and you need only contemplate having your daemon exist gracefully (and quickly) at system shutdown when the system sends it a SIGTERM signal (see /etc/init.d/sendsigs for details).

Hope something from that helps.