4

I have created a daemon that copies data from source to destination directory.

I have named it cpd (copy daemon). It periodically runs this cp command: cp src dest

But if I need to change the interval of this cp command execution, how should I communicate with the cpd daemon?

For example: cpd -p 120 --> where -p indicates period and 120 is in seconds.

PS: "I know how to start a background process: create a child and exit from parent process, set new session id, close inherited standard file descriptors, change working directory. The standard steps to create a daemon. I am also using syslog to log status messages after each command are executed."

Reference for daemon creation

@Paul: So i need a config file like this one below. and when I run without -d option I should signal the daemon to read this file and change its variables, behaviour accordingly. Is that right?

# Example configuration file for cpd - An test Linux daemon.
# Comments start with a # and are ignored.
# Configuration options are delimited by = and ;
# Example:
#    arg=val;
verbose_logging_enabled=true;
daemon_enabled=false;
config_file_path=/etc/cpd.conf;
source_path=/home/Documents/Source;
destination_path=/home/Documents/Destination;
Community
  • 1
  • 1
RootPhoenix
  • 1,517
  • 20
  • 37
  • 2
    So you are basically asking, "How can one program communicate with another program under Linux?" Some commonly used methods are files, named pipes, sockets, signals. For example, [inetd](http://www.linuxmanpages.com/man8/inetd.8.php) will re-read its configuration file when it receives a SIGHUP. – Paul Sep 26 '14 at 08:28
  • related: http://stackoverflow.com/questions/9557631/how-do-programs-communicate-with-each-other – Paul Sep 26 '14 at 08:33
  • 1
    You very well may need more code, but you don't have to put it in a separate program. A single program can have a main program with an `if args contain "-d" then call run_daemon(args) else call send_to_daemon(args)` . The problem is you need to write `run_daemon()` and `send_to_daemon()` and decide on all the details of the protocol. – Paul Sep 26 '14 at 08:37
  • In python: [How to communicate with a running python daemon?](http://stackoverflow.com/questions/656933/communicating-with-a-running-python-daemon) – Paul Sep 26 '14 at 08:49
  • hi @Paul , I am working with C for now. So, AFAIHUnderstood I use the same program with different options suppied as argv...if -d then I send some information to a RUNNING daemon using any of the IPC's lets say UNIX sockets. if i donot send the -d option i simply create my daemon for the first time. is this approach valid. – RootPhoenix Sep 26 '14 at 08:54
  • 1
    That's fine. Now if you look in the directory /var/run, you may find some pid files left by other daemons. These files contain one number, the process ID number of the running daemon. By creating/reading/writing that file your command line process can become aware of the pid of the daemon, or if there is one running at all. That's how the command line process can know which pid to send a SIGNAL to, to get the daemon to read its config file or otherwise check its "inbox". If you want to use sockets, you have to use asynchronous calls like select() which is harder. – Paul Sep 26 '14 at 08:57
  • GNA, actually the standard is the opposite of what you said. -d usually means run the daemon, and no -d means talk to the daemon. – Paul Sep 26 '14 at 09:00
  • Sockets and C under GNU/Linux: https://www.gnu.org/software/libc/manual/html_node/Sockets.html#Sockets – Paul Sep 26 '14 at 09:10
  • @Paul ..See edited question since lack of space here – RootPhoenix Sep 26 '14 at 10:50
  • Yes, thats one way to do it. – Paul Sep 26 '14 at 10:52
  • Time for some sleep here... – Paul Sep 26 '14 at 10:53

3 Answers3

4

It depends how much you want to communicate to the running daemon.

If you want to have a whole conversation, then you're going to have to think about sockets and listeners and protocols and all. That's quite a bit of work.

Your requirement sounds quite simple, though. A conventional thing to do in this case is to have your daemon install a signal handler for HUP (see sigaction or its equivalent on your unix flavour). When the program receives that signal, the handler simply re-reads a configuration file (or rather does something which causes the daemon to re-read that in some way). Thus the sequence is:

% vi .../my-daemon.config
% kill -HUP <daemon-pid>

It's common to have the daemon write its PID on startup to a file in /var/run, so that the second line would be

% kill -HUP `cat /var/run/mydaemon.pid`

If you want to be fancy and automate that, then you could add some option to the daemon which makes the configuration changes and then sends the signal (see kill(2)).

A further point is that the signals USR1 and USR2 are intended for this sort of communication. If you install signal handlers for HUP, USR1 and USR2, then that's three different types of poke you can administer to your daemon. That might be all you need.

Norman Gray
  • 10,851
  • 2
  • 26
  • 50
1

You could have your process listen for SIGUSR1 and SIGUSR2 (user-defined signals). On SIGUSR1 it increments the copy interval by some predefined value and on SIGUSR2 it decrements it. You do this easily:

//call at startup
signal(SIGUSR1, SIGUSR1Handler);
signal(SIGUSR2, SIGUSR2Handler);

//handlers:
void  SIGUSR1Handler(int sig)
{
    //increment copy interval
    //maybe print a message with the new value
}

void  SIGUSR2Handler(int sig)
{
    //increment copy interval
    //maybe print a message with the new value
}

This is really no different than what others have already mentioned in terms of how you can communicate with your daemon process, but adds the little practical side of not needing any external configuration.

xpa1492
  • 1,818
  • 1
  • 7
  • 17
  • hi @xpa1492 custom signal handlers would mean only predefined intervals are allowed. but I want exact value passed by user to be specified. Hence i think the SIGHUP solution is acceptable right now – RootPhoenix Oct 14 '14 at 05:24
0

If your daemon has nothing to do most of the time, why not just get it to do a 'blocking' read () ?. i.e just wait until a file is filled with a command and then read it. The command line can just be a script that writes to the command-file.

Humpity
  • 33
  • 5
  • Well, its not about whether my daemon does something useful, standard approach would be better, Also i would get to know it. – RootPhoenix Oct 14 '14 at 05:25