UPDATE: the poster above this was thinking of Proc::Daemon not Proc::Background, please ignore this entire thread unless you want to see our less-than-interesting path to figuring this out...

You can't decide whether there is another instance of yourself already running before Proc::Background::Init is run and still be able to send some text back to the console.

I've always used it for launching processes, not copies of myself (and never Proc::Background inside of a plain fork either), so I have not encountered that problem. For instance, I am doing stuff like launching bzip2 or InstallShield and keeping a Tk app responsive at the same time. Actually, I'm not quite sure how you encountered that particular scenario...

I'm sure POE has good ways to do this sort of thing as well, but this at least has provided a lightweight mechanism for my uses.

In the following code sample the database connection cannot be started until after Proc::Background::Init because DBI connections do not survive forks. The fork has to happen before the potentially fatal register_process() because you wouldn't want to write the wrong pid to the process list. This leaves you with no way to report a fatal exit to the console that just started the application.

exit main( @ARGV );

sub main
{
    eval
    {
        Sys::Syslog::openlog( $SYSLOG_IDENT, '', $SYSLOG_FACILITY );
        1;
    }
    or Carp::croak( $@ );
 
    Proc::Background::Init();

    db_start(); # <- The database connection cannot be established

    ...
}

sub db_start
{
    return if $::DBH;
    main::log_debug( "DBI->connect" ) if $::DEBUG;
    $::DBH = DBI->connect
        ( $::DBI_DSN,
          $::DBI_USER,
          $::DBI_PASS,
          { RaiseError => 1,
            PrintError => 0,
            AutoCommit => 1 } )
        or main::log_emerg( 'emerg', "Error connecting to database: $D
+BI::errstr" );

    # Potentially fatal - if the process is already running that would
+ violate the table's constraint system.
    $::DBH->do( "SELECT register_process( ?, ? )",
                undef,
                File::Basename::basename( $0 ),
                $$ );
    
    return 1;
}
[download]

ProcBackground::Init() is not mentioned on the Proc::Background CPAN page, hence I have not used it. I have been using the OO interface as documented in the POD.

And again, the documentation on that CPAN page is about using Proc::Background to start outside processes, not to start pieces of your program in a new process. It is not a drop-in fork replacement, nor do the docs imply this to me.

METHODS

new [options] command, [arg, [arg, ...]]
new [options] 'command [arg [arg ...]]'
[download]

All of these functions take commands as arguments, as they would be invoked by system(""). Perhaps you are using an internal API you are not meant to use? It is not documented!