1MooseX::Daemonize::CoreU(s3e)r Contributed Perl DocumentaMtoioosneX::Daemonize::Core(3)
2
6 MooseX::Daemonize::Core - A Role with the core daemonization features
7
9 package My::Daemon;
10 use Moose;
11 with 'MooseX::Daemonize::Core';
13 sub start {
15 my $self = shift;
16 # daemonize me ...
17 $self->daemonize;
18 # return from the parent,...
19 return unless $self->is_daemon;
20 # but continue on in the child (daemon)
21 }
22
24 This is the basic daemonization Role, it provides a few methods (see
25 below) and the minimum features needed to properly daemonize your code.
26 Important Notes
28 None of the methods in this role will exit the parent process for you,
29 it only forks and detaches your child (daemon) process. It is your
30 responsibility to exit the parent process in some way.
31 There is no PID or PID file management in this role, that is your
33 responsibility (see some of the other roles in this distro for that).
34
36 is_daemon (is = rw, isa => Bool)>
37 This attribute is used to signal if we are within the daemon
38 process or not.
39
41 daemon_fork (%options)
42 This forks off the child process to be daemonized. Just as with the
43 built in fork, it returns the child pid to the parent process, 0 to
44 the child process. It will also set the is_daemon flag
45 appropriately.
46 The %options available for this function are:
48 ignore_zombies
50 Setting this key to a true value will result in setting the
51 $SIG{CHLD} handler to "IGNORE". This tells perl to clean up
52 zombie processes. By default, and for the most part you don't
53 need it, only when you turn off the double fork behavior (with
54 the no_double_fork option) in "daemon_detach" do you sometimes
55 want this behavior.
56 daemon_detach (%options)
58 This detaches the new child process from the terminal by doing the
59 following things.
60 Becomes a session leader
62 This detaches the program from the controlling terminal, it is
63 accomplished by calling POSIX::setsid.
64 Performing the double-fork
66 See below for information on how to change this part of the
67 process.
68 Changes the current working directory to "/"
70 This is standard daemon behavior, if you want a different
71 working directory then simply change it later in your daemons
72 code.
73 Clears the file creation mask.
75 Closes all open file descriptors.
76 See below for information on how to change this part of the
77 process.
78 Reopen STDERR, STDOUT & STDIN to /dev/null
80 This behavior can be controlled slightly though the
81 MX_DAEMON_STDERR and MX_DAEMON_STDOUT environment variables. It
82 will look for a filename in either of these variables and
83 redirect STDOUT and/or STDERR to those files. This is useful
84 for debugging and/or testing purposes.
85 The %options available for this function are:
87 no_double_fork
89 Setting this option to true will cause this method to not
90 perform the typical double-fork, which is extra added
91 protection from your process accidentally aquiring a
92 controlling terminal. More information can be found above, and
93 by Googling "double fork daemonize".
94 If you the double-fork behavior off, you might want to enable
96 the ignore_zombies behavior in the "daemon_fork" method.
97 dont_close_all_files
99 Setting this option to true will cause it to skip closing all
100 the filehandles, this is useful if you are opening things like
101 sockets and such in the pre-fork.
102 NOTE
104 If called from within the parent process (the is_daemon flag is set
106 to false), this method will simply return and do nothing.
107 daemonize (%options)
109 This will simply call "daemon_fork" followed by "daemon_detach", it
110 will pass any %options onto both methods.
111 meta()
113 The "meta()" method from Class::MOP::Class
114
116 Note about double fork
117 Taken from
118 <http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/66012> in
119 a comment entitled The second fork _is_ necessary by Jonathan
120 Bartlett, it is not the definitive statement on the issue, but it's
121 clear and well written enough so I decided to reproduce it here.
122 The first fork accomplishes two things - allow the shell to return,
124 and allow you to do a setsid().
125 The setsid() removes yourself from your controlling terminal. You
127 see, before, you were still listed as a job of your previous process,
128 and therefore the user might accidentally send you a signal. setsid()
129 gives you a new session, and removes the existing controlling terminal.
130 The problem is, you are now a session leader. As a session leader, if
132 you open a file descriptor that is a terminal, it will become your
133 controlling terminal (oops!). Therefore, the second fork makes you NOT
134 be a session leader. Only session leaders can acquire a controlling
135 terminal, so you can open up any file you wish without worrying that
136 it will make you a controlling terminal.
137 So - first fork - allow shell to return, and permit you to call setsid()
139 Second fork - prevent you from accidentally reacquiring a controlling
141 terminal.
142 That said, you don't always want this to be the behavior, so you
144 are free to specify otherwise using the %options.
145 Note about zombies
147 Doing the double fork (see above) tends to get rid of your zombies
148 since by the time you have double forked your daemon process is
149 then owned by the init process. However, sometimes the double-fork
150 is more than you really need, and you want to keep your daemon
151 processes a little closer to you. In this case you have to watch
152 out for zombies, you can avoid then by just setting the
153 "ignore_zombies" option (see above).
154
156 These variables are best just used for debugging and/or testing, but
157 not used for actual logging. For that, you should reopen STDOUT/ERR on
158 your own.
159 MX_DAEMON_STDOUT
161 A filename to redirect the daemon STDOUT to.
162 MX_DAEMON_STDERR
164 A filename to redirect the daemon STDERR to.
165
167 Moose::Role, POSIX
168
170 None reported.
171
173 No bugs have been reported.
174 Please report any bugs or feature requests to
176 "bug-acme-dahut-call@rt.cpan.org", or through the web interface at
177 <http://rt.cpan.org>.
178
180 Proc::Daemon
181 This code is based HEAVILY on Proc::Daemon, we originally depended on
183 it, but we needed some more flexibility, so instead we just stole the
184 code.
185
187 Stevan Little "<stevan.little@iinteractive.com>"
188
190 Copyright (c) 2007-2008, Chris Prather "<perigrin@cpan.org>". All
191 rights reserved.
192 Portions heavily borrowed from Proc::Daemon which is copyright Earl
194 Hood.
195 This module is free software; you can redistribute it and/or modify it
197 under the same terms as Perl itself. See perlartistic.
198
200 BECAUSE THIS SOFTWARE IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY
201 FOR THE SOFTWARE, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT
202 WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER
203 PARTIES PROVIDE THE SOFTWARE "AS IS" WITHOUT WARRANTY OF ANY KIND,
204 EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
205 WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE
206 ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE SOFTWARE IS WITH
207 YOU. SHOULD THE SOFTWARE PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL
208 NECESSARY SERVICING, REPAIR, OR CORRECTION.
209 IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
211 WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR
212 REDISTRIBUTE THE SOFTWARE AS PERMITTED BY THE ABOVE LICENCE, BE LIABLE
213 TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL, OR
214 CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE
215 SOFTWARE (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING
216 RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A
217 FAILURE OF THE SOFTWARE TO OPERATE WITH ANY OTHER SOFTWARE), EVEN IF
218 SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH
219 DAMAGES.
220perl v5.12.0 2009-10-05 MooseX::Daemonize::Core(3)