There is a lack of examples for how to use the module, from my digging. While the documentation is complete, the lack of practical examples made it hard for me to envision how exactly to accomplish what I wished to do. I will freely admit to being spoiled by the great documentation on modules like XML::Twig :D.

The Init method (still, less so than before, though) has the appearance of voodoo; Timing of its call seems to be very important, particularly if you want to limit the daemon to a single instance, which for my purposes is important as the task that I'm firing is exceptionally cpu intensive and long running. This tripped me up QUITE a few times until I realized I could call Status without having to do an Init. This blindingly bright lightbulb allowed me to get the important stuff (start, stop, status) to behave the way I desired.

While the terse example on the documentation is valid, it was so far away from my use case (limit to single instance), I couldn't align it with what I wanted to do. The example above was my path to discovery of how to fix my ignorance.

Most of the OP code is not necessary with Proc::Daemon either. I see very little difference between the utility, options, and syntactic verbosity of the two packages; only the init stuff seems an exception.

Could you show an example? E.g. what would the example in Re^2: Practical Proc::Daemon example look like if Proc::Daemon were used?

simple additions

I added these to the example:

GetOptions(
    'daemon!' => \$daemonize,
    "help"    => \&usage,
    "reload"  => \&reload,
    "restart" => \&restart,
    "start"   => \&run,
    "status"  => \&status,
    "stop"    => \&stop
    ) or &usage;
exit(0);
# ==================================================
sub usage
{
    my ($opt_name, $opt_value) = @_;
    print "your usage text goes here...\n";
    exit(0);
}
# ==================================================
sub reload
{
    my ($opt_name, $opt_value) = @_;
    print "reload process not implemented.\n";
}
# ==================================================
sub restart
{
    my ($opt_name, $opt_value) = @_;
    &stop;
    &run;
}
# ==================================================
[download]

Yes, they are obvious, but since that is about all I did to the example to make it a "complete" test for my system, I figured that I'd toss it back a'cha.

THANKS!!!

It seems as though Proc::Daemon makes you do a lot of extra work. What if you didn't have to re-invent so many wheels? Here's another way:

#!/usr/bin/env perl
# weather_watch.pl
use strict;
use Getopt::Long;
use JSON::XS;
use LWP::Simple;
use Sys::Syslog;

my $app = bless { 
    city => 'London,uk',
};

GetOptions(
    $app,
    'city=s',
);

$app->init;
$app->run;

sub init {
    my ($app) = @_;

    openlog($0, 'pid', 'user');
    syslog("info", "Starting up");
    $SIG{TERM} = sub {
        $app->{should_stop} = 1;
    };
}

sub run {
    my ($app) = @_;

    my $url = "http://api.openweathermap.org/data/2.5/weather?q=$app->
+{city}";
    until ( $app->{should_stop} ) {
        if ( my $json = get($url) ) {
            my $data = decode_json($json);
            syslog("info", "Temperature is $data->{main}{temp}");
            syslog("info", "Wind speed is $data->{wind}{speed}");
        }
        sleep 5;        
    }
    syslog("info", "Shutting down");
    closelog();
}
[download]

The example program is not cluttered with daemonization logic and to run that in non daemon mode, just run it. To add daemonization, create a little script (all off this could be done in one script but for clarity I prefer to keep them separate):

#!/usr/bin/perl
# weathermon
use warnings;
use strict;
use Daemon::Control;
use Getopt::Long;

GetOptions(
    \ my %OPT,
    'city=s',
);
 
exit Daemon::Control->new(
    name        => "Weather watch daemon",
    path        => '/home/arun/test/weathermon',
 
    program     => '/home/arun/test/weather_watch.pl',
    program_args => [ '--city', $OPT{city} ],
 
    pid_file    => '/tmp/weathermon.pid',
)->run;
[download]

Now we get all this for free:

% ./weathermon status                   
Weather watch daemon                                      [Not Running
+]
% ./weathermon start 
Weather watch daemon                                          [Started
+]
% ./weathermon status
Weather watch daemon                                          [Running
+]
% ./weathermon stop  
Weather watch daemon                                          [Stopped
+]
% ./weathermon start -c Miami,us        
Weather watch daemon                                          [Started
+]
% ./weathermon restart          
Weather watch daemon                                          [Stopped
+]
Weather watch daemon                                          [Started
+]
%
[download]

This is a bit late, but the parent came up due to other comments, so I thought I'd chime in.

I tried Proc::Daemon, but it didn't work cross-OS, so I went with Proc::Background instead, which did what I wanted. I must admit that I spent a great deal of time using other distributions to turn things into a proper Windows service while on Windows, and changing up to Proc::Daemon when on Unix, but it was too much work.

This is a real-life, in use, frequently used example of Proc::Background that works on both Windows and Unix. Here is where I actually fork out.

At the time I wrote that code, I was testing forking-type code heavily, and I am still looking for the be-all, end-all, but to suit both OS types simultaneously isn't easy, by any stretch.

SWEETNESS!!!!!

Thanks for the code! I had been tinkering about with putting something together for a script which I needed to make a daemon out of. The script worked perfectly, so I did NOT want to pull it apart and split it up and such -- it simply needed to become a background process.

I got it working; I got it doing the fork, etc. But the "complex" part of checking to see if it is running, starting it, stopping it, etc, etc, was all becoming daunting. Yes, I could keep hacking away at it, and I'd have it done. But why? I just KNEW there had to be a better way!!!

Thanks to this one example, In less than an hour I replaced code I had spent days working on and testing, and am virtually finished with the project!

The only problem I have is I can only ++ this one time!

I joined this forum solely to say "Thank You".

I am not a Perl Monk, I am a complete novice even after too many years. Time and time again I keep coming back here to hear pearls of wisdom.

This description of how to use Daemon::Control was great and worked first time. It's saved me so much hassle.

Thank you to everybody for putting so much time and effort into so many clear answers. We are often quick to criticise and carp, less quick to praise and say thanks. This is one small way of correcting that.

Best wishes,

Rob.

Have you looked at DBI's connect_cached() ? Used with care it can help in a situation like yours.



The way forward always starts with a minimal test.