Infinte perl script

r.joseph has asked for the wisdom of the Perl Monks concerning the following question:

Replies are listed 'Best First'.
Re (tilly) 1: Infinte perl script - Part 2 by tilly (Archbishop) on Jan 06, 2001 at 06:59 UTC
To have it survive your exiting you could take a look at Proc::Daemon. But if you want it up all of the time you absolutely should either periodically try to launch it from cron or else put it in your rc.d. A very common Unix mistake is to just leave critical processes running but not take the necessary steps to handle a reboot. Then a few months later when the project may have been all forgotten about (and the person may have moved on) when the box is rebooted for some reason stuff just starts failing for no apparent reason. If you know people who are uncomfortable about rebooting Unix, people in their environment are probably making that mistake. Just because you can leave Unix up for months at a time doesn't mean that you should let people get in the habit of relying on that. If this is a problem then you should get into the habit of rebooting the servers on a regular basis whether or not they need it. Of course if users and developers are properly trained then there is no reason not to leave it on. But this is a user issue, not an OS problem. However if you are running Windows NT you should reboot periodically on general principle. And that is an OS issue. (I hear that Win2K is better in this respect, but I am not running it.) (Of course my laptop has not been rebooted in 95 days, and was rebooted then only because my wife wanted to move it for a bit...)	[reply]
Re: Infinte perl script - Part 2 by ichimunki (Priest) on Jan 06, 2001 at 07:00 UTC
I would tell you that "nohup ./script.pl &" will disassociate the process from the controlling terminal immediately, but I really don't think this is the optimal way to turn a process into a background process. There is a more suitable method mentioned in perlman:perlfaq8.	[reply]
Re: Infinte perl script - Part 2 by kschwab (Vicar) on Jan 06, 2001 at 07:22 UTC
If you fork, then have the child become a process group leader (via setsid), you too can be a daemon... `use POSIX qw(setsid); if (fork()) { exit; } else { setsid; } rest of your code here...` [download]	[reply] [d/l]
Re: Infinte perl script - Part 2 by repson (Chaplain) on Jan 06, 2001 at 07:24 UTC
You don't need root access to run thing in cron (I only know linux but I assume cron would be constant). Just type: `% crontab -ujoseph -e` This edits the personal cron for user joseph instead of the main system one. For more information talk to the man (ie `% man crontab`) Another choice is the `at` command. You could end every invocation of your program with: `open AT,"/usr/bin/at now + 20 minutes" or die; print AT "/usr/bin/perl $0\nEOF"; close AT;` [download] At least thats my untested guesses on how to do it.	[reply] [d/l] [select]
Re (tilly) 2: Infinte perl script - Part 2 by tilly (Archbishop) on Jan 06, 2001 at 19:02 UTC
This advice is only somewhat true. Whether or not a particular machine allows cron to be run from user accounts depends on how that machine is configured. Look up the crontab command on your machine. Generally there can be files (on mine /etc/cron.allow and /etc/cron.deny) which control who can use cron. In general it is not a good idea to have critical production jobs running from user accounts. Have production users for that... Also note that crons are something which I do not recommend editing directly. They are usually important, and are too easy to mess up. Instead have a file under version control (which I tend to name "crontab", YMMV) which you edit, and then do `crontab crontab` to install. That way if you do something wrong, you know you can get back to your old crontab very easily. Many people use named backups of key files instead of real version control. It kind of works, but real version control is much, much better.	[reply]
screen(1) (Was: Infinte perl script - Part 2) by rlk (Pilgrim) on Jan 06, 2001 at 11:36 UTC
One thing that I haven't seen anybody mention yet is the `screen` command. The nice thing about `screen` is that it "multiplexes a physical terminal between several processes (typically interactive shells)". This allows you to start a program which prints status messages to STDOUT or STDERR, log out, log back in later, and reattach the process's standard input and output to your terminal to see what it's been up to. -- Ryan Koppenhaver, Aspiring Perl Hacker "I ask for so little. Just fear me, love me, do as I say and I will be your slave."	[reply]
Re: Infinte perl script - Part 2 by Fastolfe (Vicar) on Jan 06, 2001 at 07:07 UTC
In a pinch, log out using your shell's logout command, not by simply closing the session. The former exits cleanly, leaving you background processes running. The latter sends all of your backgrounded processes a HUP signal, which is probably killing your script. But heed the advice of others and consider turning your script into a "real" daemon by disassociating it from the terminal to start with.	[reply]
Re: Infinte perl script - Part 2 by Petruchio (Vicar) on Jan 07, 2001 at 02:00 UTC
...which I access via telnet. Now, my host is just a friend, so I have root This is offtopic, but I had to say it. DON'T USE THE ROOT ACCOUNT VIA TELNET! Really. Truly. Seriously. Convince your friend to let you install sshd, and ssh into the box. If you can, convince him to let you shut down telnetd entirely (as well as any other unnecessary services). If you continue to do as you are doing, it's a matter of time before this system becomes a plaything for vandals.	[reply]
Re: Infinte perl script - Part 2 by Anonymous Monk on Jan 06, 2001 at 20:30 UTC
my guess is using nohup, i still use nohup sometimes to start ftp sessions on the unix shell box which do no die right after i disconnect from my dial provider. basically: nohup programmfile and the you disconnect But i have managed to write c and perl script in the past for an ISP which manager dial up line and DO NOT die when user is disconnected (they need to write logout time into the database). The trick is to handle HUP signal which all your processes get when you logout. Default for this signal is to terminate the process. Also, i don't remenber exactly, there maybe a couple more signal to wait for (SIGQUIT?). So: man nohup man signal and of course perldoc on the signal handling. Good luck! Artem Koutchine matrix@chat.ru	[reply]