Re: is possible start some actions with Perl without Cron?
Ok, since no one wanted to help me with this, I needed to look through some googled stuff to find the answer myself. In the spirit of helping beginers (which of course I am) I'll post what I found! (This material is from page 2 of the tutorial there): quote There are several rules or characteristics that most daemons possess. If a daemon does not follow these basic rules, it will most likely become a demon and wreak havoc on your system. Fork and Exit The first thing a daemon should do is fork() a child process and have the parent process exit(). This is necessary for several reasons. First, it disassociates the process from the controlling terminal, or the login shell. Second, it removes the process from the process group that initiated the program. This ensures that the process is not a process group leader, which is required for setsid() to run successfully. Call setsid() setsid() is a POSIX function that turns the process into a session leader, group leader, and ensures that it doesn't have a controlling terminal. Change Working directory The current working directory should be changed with chdir to the root directory (/). This is necessary to avoid using a working directory that resides on a mounted partition. If the process is started on a mounted partition, the system administrator wouldn't be able to unmount the partition until the process was halted. You could, of course, specify a different working directory as long as it doesn't reside on a remotely mounted partition. File Creation Mode The umask determines the default permissions new files are assigned. Setting umask to 0 removes the defaults that might otherwise disable permissions the daemon intended to enable when creating files. Close Unneeded File Handles Besides closing any filehandles that might have been opened, daemons often redirect STDIN to read from, and STDOUT and STDERR to write to /dev/null. open STDIN, '/dev/null' or die Can't read /dev/null: $!; open STDOUT, '/dev/null'; open STDERR, '/dev/null'; Logging Messages In some cases, you may want to record an error or messages to a log file on the system. This can be accomplished by redirecting STDOUT and STDERR to one or more log files. open STDOUT, $access_log or die Can't write to $access_log: $!; open STDERR, $error_log or die Can't write to $error_log: $!; /quote This material was all found at the following link: http://www.webreference.com/perl/tutorial/9/ and is authored by ... well, here's a cut-n-paste of the about page: About Mother of Perl - Mother of Perl is a free biweekly how-to devoted to all things Perl. Perl has been an integral part of the Web developer's toolkit for years now. There are probably more Perl scripts, tools, and libraries available for Web Development than any other modern language. This column will attempt to address the needs and concerns of the Desparate Perl Hacker© by providing practical, powerful, and elegant solutions to everyday problems in 100 lines of code or less. If you would like to see a topic or problem area covered in Mother of Perl, please let me know by sending me some feedback. The Author - Jonathan Eisenzopf is an author, teacher, and consultant who has worked with companies like Netscape, Chrysler, Mecklermedia, Bell Atlantic, and Litton/PRC to deploy large scale Web-based information systems. He is presently a Principal Software Engineer and VP of Technology at Whirlwind Interactive, based in the Washington D.C. area. Jonathan is active in the Perl and XML communities by delivering presentations to user groups, contributing articles to publications such as The Perl Journal, authoring modules for CPAN, and maintains www.perlxml.com, an information clearinghouse for Perl and XML resources. Jonathan is also a co-author of an upcoming book from O'Reilly and Associates covering Perl and XML. On Tue, 24 Aug 2004 15:59:57 -0500, Errin Larsen [EMAIL PROTECTED] wrote: Hi, Can you help me understand the below a little better. As I understand what's going on, the Process (let's say PID=100) spawns a child with the fork() function (let's say PID=200). This (200) is assigned to $pid in the parent, and zero (0) is assigned to $pid in the child. So, what does my $pid=fork() resolve to in each case? I'll assume that it resolves to the PID that fork returns. So, in the parent, the statement resolves to 200 and the unless statement doesn't resolve. In the child, the statement resolves to 0 and the unless statement DOES resolve. So, the parent prints a message to STDOUT and quits, while the child keeps on running (in the little do/while loop) doing that stuff that's in there :) Ok ... so, um, why go through all this? Why not just write your do/while block and just execute it in the background on the command line? is fork() doing something else that helps a daemon that I'm not aware of? --Errin On Sat, 21 Aug 2004 09:53:23 -0400, Adam Rosi-Kessel [EMAIL PROTECTED] wrote: SNIP
Re: is possible start some actions with Perl without Cron?
On Tue, Aug 24, 2004 at 03:59:57PM -0500, Errin Larsen wrote:
As I understand what's going on, the Process (let's say PID=100)
spawns a child with the fork() function (let's say PID=200). This
(200) is assigned to $pid in the parent, and zero (0) is assigned to
$pid in the child. So, what does my $pid=fork() resolve to in each
case? I'll assume that it resolves to the PID that fork returns. So,
in the parent, the statement resolves to 200 and the unless statement
doesn't resolve. In the child, the statement resolves to 0 and the
unless statement DOES resolve. So, the parent prints a message to
STDOUT and quits, while the child keeps on running (in the little
do/while loop) doing that stuff that's in there :)
That sounds about right. At the fork() call the program spawns into two
processes; the child gets 0 back from fork() (if it wants to know its own
pid, it can just look at $$) and the parent gets the child's pid back (in
case it wants to send signals to the child). You'll notice a lot of
daemons store the child pid in /var/run, e.g., apache.pid, so when you
call the daemon script later it can send the proper signal to the
now-detached child.
Usually, you'll want to implement custom signal handling in the child
(i.e., local $SIG{HUP} = \SomeCode).
Ok ... so, um, why go through all this? Why not just write your
do/while block and just execute it in the background on the command
line? is fork() doing something else that helps a daemon that I'm not
aware of?
I guess primarily because you don't want your user to have to background
the task. If you're writing a daemon script thats going to go in
/etc/init.d, it has to detach itself--the initscripts aren't going to
put it in the background for you.
If you background a task from the shell, then the shell will be its
parent. If you detach a daemon like my code sample below, the parent
dies and the child is adopted by init (pid 1). I can't think off the top
of my head why this is important, but it is a difference.
I think just as a matter of good programming style, if your program is
always suppose to background itself, you should have the program
background itself, rather than relying on the user to background it.
On Sat, 21 Aug 2004 09:53:23 -0400, Adam Rosi-Kessel
Here's the skeleton of it:
unless (my $pid = fork()) {
do {
SendEmailToUsers;
sleep 3 * 24 * 60 * 60;
} while (1);
}
print Starting email daemon...\n;
--
Adam Rosi-Kessel
http://adam.rosi-kessel.org
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/ http://learn.perl.org/first-response
Re: is possible start some actions with Perl without Cron?
Hi,
Can you help me understand the below a little better.
As I understand what's going on, the Process (let's say PID=100)
spawns a child with the fork() function (let's say PID=200). This
(200) is assigned to $pid in the parent, and zero (0) is assigned to
$pid in the child. So, what does my $pid=fork() resolve to in each
case? I'll assume that it resolves to the PID that fork returns. So,
in the parent, the statement resolves to 200 and the unless statement
doesn't resolve. In the child, the statement resolves to 0 and the
unless statement DOES resolve. So, the parent prints a message to
STDOUT and quits, while the child keeps on running (in the little
do/while loop) doing that stuff that's in there :) Ok ... so, um, why
go through all this? Why not just write your do/while block and just
execute it in the background on the command line? is fork() doing
something else that helps a daemon that I'm not aware of?
--Errin
On Sat, 21 Aug 2004 09:53:23 -0400, Adam Rosi-Kessel
[EMAIL PROTECTED] wrote:
SNIP
Here's the skeleton of it:
unless (my $pid = fork()) {
do {
SendEmailToUsers;
sleep 3 * 24 * 60 * 60;
} while (1);
}
print Starting email daemon...\n;
-
That's all. This will run indefinitely, and every three days run the
subroutine SendEmailToUsers. You obviously need to add a lot more to
SNIP
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/ http://learn.perl.org/first-response
Re: is possible start some actions with Perl without Cron?
On Sat, Aug 21, 2004 at 01:11:41AM +0200, Maxipoint Rep Office wrote:
Have you some useful URL about that?
is possible start some actions with Perl without Cron?
for example send email to users from database after 3 days or delete
something from database automaticaly after 3 day with Perl but
without Cron?
Here's the skeleton of it:
unless (my $pid = fork()) {
do {
SendEmailToUsers;
sleep 3 * 24 * 60 * 60;
} while (1);
}
print Starting email daemon...\n;
-
That's all. This will run indefinitely, and every three days run the
subroutine SendEmailToUsers. You obviously need to add a lot more to
have a sensible daemon: you'd at least want to check to make sure it was
not already running when you started it, and provide a system to shut the
daemon down.
--
Adam Rosi-Kessel
http://adam.rosi-kessel.org
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/ http://learn.perl.org/first-response
is possible start some actions with Perl without Cron?
is possible start some actions with Perl without Cron? for example send email to users from database after 3 days or delete something from database automaticaly after 3 day with Perl but without Cron? -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] http://learn.perl.org/ http://learn.perl.org/first-response
Re: is possible start some actions with Perl without Cron?
Maxipoint Rep Office wrote (also to comp.lang.perl.misc): is possible start some actions with Perl without Cron? Do not multi-post! http://www.uwasa.fi/~ts/http/crospost.html -- Gunnar Hjalmarsson Email: http://www.gunnar.cc/cgi-bin/contact.pl -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] http://learn.perl.org/ http://learn.perl.org/first-response
RE: is possible start some actions with Perl without Cron?
Maxipoint Rep Office wrote: is possible start some actions with Perl without Cron? for example send email to users from database after 3 days or delete something from database automaticaly after 3 day with Perl but without Cron? Yes. You would write the Perl as a daemon and have it run in background. Have it work and sleep as you desire it to. Wags ;) *** This message contains information that is confidential and proprietary to FedEx Freight or its affiliates. It is intended only for the recipient named and for the express purpose(s) described therein. Any other use is prohibited. *** -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] http://learn.perl.org/ http://learn.perl.org/first-response
RE: is possible start some actions with Perl without Cron?
Have you some useful URL about that? -Original Message- From: Wagner, David --- Senior Programmer Analyst --- WGO [mailto:[EMAIL PROTECTED] Sent: Saturday, August 21, 2004 1:07 AM To: Maxipoint Rep Office; [EMAIL PROTECTED] Subject: RE: is possible start some actions with Perl without Cron? Maxipoint Rep Office wrote: is possible start some actions with Perl without Cron? for example send email to users from database after 3 days or delete something from database automaticaly after 3 day with Perl but without Cron? Yes. You would write the Perl as a daemon and have it run in background. Have it work and sleep as you desire it to. Wags ;) *** This message contains information that is confidential and proprietary to FedEx Freight or its affiliates. It is intended only for the recipient named and for the express purpose(s) described therein. Any other use is prohibited. *** -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] http://learn.perl.org/ http://learn.perl.org/first-response
RE: is possible start some actions with Perl without Cron?
Maxipoint Rep Office wrote: Have you some useful URL about that? Not really. You should look at CPAN for daemon or background processing. Then you just need to understand the Perl necessary to get what you want done. Obviously easier said than done, but layout what you want to do, then attmept to do a portion of it. Run into problems, then show the snippet of code to the list and usually someone will be able to give some help. Wags ;) -Original Message- From: Wagner, David --- Senior Programmer Analyst --- WGO [mailto:[EMAIL PROTECTED] Sent: Saturday, August 21, 2004 1:07 AM To: Maxipoint Rep Office; [EMAIL PROTECTED] Subject: RE: is possible start some actions with Perl without Cron? Maxipoint Rep Office wrote: is possible start some actions with Perl without Cron? for example send email to users from database after 3 days or delete something from database automaticaly after 3 day with Perl but without Cron? Yes. You would write the Perl as a daemon and have it run in background. Have it work and sleep as you desire it to. Wags ;) *** This message contains information that is confidential and proprietary to FedEx Freight or its affiliates. It is intended only for the recipient named and for the express purpose(s) described therein. Any other use is prohibited. *** -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] http://learn.perl.org/ http://learn.perl.org/first-response
