Contents:
All functions and classes that Daemons provides reside in this module.
Daemons is normally invoked by one of the following four ways:
- Daemons.run(script, options): This is used in wrapper-scripts that are supposed to control other ruby scripts or external applications. Control is completely passed to the daemons library. Such wrapper script need to be invoked with command line options like ‘start’ or ‘stop’ to do anything useful.
- Daemons.run_proc(app_name, options) { (…) }: This is used in wrapper-scripts that are supposed to control a proc. Control is completely passed to the daemons library. Such wrapper script need to be invoked with command line options like ‘start’ or ‘stop’ to do anything useful.
- Daemons.call(options) { block }: Execute the block in a new daemon. Daemons.call will return immediately after spawning the daemon with the new Application object as a return value.
- Daemons.daemonize(options): Daemonize the currently runnig process, i.e. the calling process will become a daemon.
What does daemons internally do with my daemons?
| or: | why do my daemons crash when they try to open a file? |
| or: | why can I not see any output from the daemon on the console (when using for example puts? |
From a technical aspect of view, daemons does the following when creating a daemon:
- Forks a child (and exits the parent process, if needed)
- Becomes a session leader (which detaches the program from the controlling terminal).
- Forks another child process and exits first child. This prevents the potential of acquiring a controlling terminal.
- Changes the current working directory to "/".
- Clears the file creation mask (sets umask to +0000+).
- Closes file descriptors (reopens STDOUT and STDERR to point to a logfile if possible).
So what does this mean for your daemons:
- the current directory is ’/’
- you cannot receive any input from the console (for example no gets)
- you cannot output anything from the daemons with puts/print unless a logfile is used
How do PidFiles work? Where are they stored?
Also, you are maybe interested in reading the documentation for the class PidFile. There you can find out about how Daemons works internally and how and where the so called PidFiles are stored.
| Classes | |
|---|---|
| Application | |
| ApplicationGroup | |
| CmdException | |
| Controller | |
| Error | |
| Exception | |
| Monitor | |
| Optparse | |
| Pid | |
| PidFile | A Pid-File is a file containing the process identification number (pid) that is stored in a well-defined location of the filesystem thus allowing other programs to find out the pid of a running script. |
| PidMem | |
| RuntimeException | |
| SystemError | |
| Constants | |
|---|---|
| VERSION | |
| Public Methods | |
|---|---|
| call | Execute the block in a new daemon. Daemons.call will return immediately after spawning the daemon with the new Application object as a return value. |
| controller | Return the internal Controller instance. |
| daemonize | Daemonize the currently runnig process, i.e. the calling process will become a daemon. |
| group | Return the internal ApplicationGroup instance. |
| run | Passes control to Daemons. This is used in wrapper-scripts that are supposed to control other ruby scripts or external applications. Control is completely passed to the daemons library. Such wrapper script should be invoked with command line options like ‘start’ or ‘stop’ to do anything useful. |
| run_ |
Passes control to Daemons. This function does the same as Daemons.run except that not a script but a proc will be run as a daemon while this script provides command line options like ‘start’ or ‘stop’ and the whole pid-file management to control the proc. |
<code/>and<pre/>for code samples.