Backup Central

Hi All,

With my new SMP Box, I'm seeing that on reboots, BackupPC will refuse to start
because it sees another process w/ it's previous PID already running. Looking
through the code, BackupPC seems to store it's own PID in two places:

status.pl
$TOPDIR/log/BackupPC.pid

It seems that on ServerShutdown() in BackupPC.pl correctly unlinks BackupPC.pid,
but nothing sets pid in status.pl to undef (or other).

Which is the more correct fix:

set status.pl to undef as part of shutdown
check PID as defined in TOPDIR/log/BackupPC.pid (if it exists)

I'm happy to make the change and submit a diff, I just don't want to go down the
wrong road.

Tony

--
Tony Nelson
Director of IT Operations
Starpoint Solutions LLC
115 Broadway, 2nd Fl
New York, NY 10006





This email message from Starpoint Solutions LLC is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. Opinions, conclusions and other information in this message that do not relate to the official business of Starpoint Solutions shall be understood as neither given nor endorsed by it.

Sorry to reply to my own post.

I found it was very simple to undef Info{'pid'} in ServerShutdown and that seems
to have solved my problem.

I don't think this will create other problems, it was fine in my "minimal
testing".

Here is a simple patch.

root < at > backuppc:/usr/local/backuppc/bin# diff -c BackupPC.orig BackupPC
*** BackupPC.orig 2004-07-26 16:24:52.000000000 -0400
--- BackupPC 2004-07-26 16:23:19.000000000 -0400
***************
*** 1807,1812 ****
--- 1807,1813 ----
%Jobs = ();
}

+ undef($Info{'pid'});
StatusWrite();
unlink("$TopDir/log/BackupPC.pid");
exit(1);



--
Tony Nelson
Director of IT Operations
Starpoint Solutions LLC
115 Broadway, 2nd Fl
New York, NY 10006


Quoting Tony Nelson <tnelson < at > starpoint.com>:

Hi All,

With my new SMP Box, I'm seeing that on reboots, BackupPC will refuse to
start
because it sees another process w/ it's previous PID already running.
Looking
through the code, BackupPC seems to store it's own PID in two places:

status.pl
$TOPDIR/log/BackupPC.pid

It seems that on ServerShutdown() in BackupPC.pl correctly unlinks
BackupPC.pid,
but nothing sets pid in status.pl to undef (or other).

Which is the more correct fix:

set status.pl to undef as part of shutdown
check PID as defined in TOPDIR/log/BackupPC.pid (if it exists)

I'm happy to make the change and submit a diff, I just don't want to go down
the
wrong road.

Tony

--
Tony Nelson
Director of IT Operations
Starpoint Solutions LLC
115 Broadway, 2nd Fl
New York, NY 10006





This email message from Starpoint Solutions LLC is for the sole use of the
intended recipient(s) and may contain confidential and privileged
information. Any unauthorized review, use, disclosure or distribution is
prohibited. If you are not the intended recipient, please contact the sender
by reply email and destroy all copies of the original message. Opinions,
conclusions and other information in this message that do not relate to the
official business of Starpoint Solutions shall be understood as neither given
nor endorsed by it.



This email message from Starpoint Solutions LLC is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. Opinions, conclusions and other information in this message that do not relate to the official business of Starpoint Solutions shall be understood as neither given nor endorsed by it.

Tony Nelson writes:

I found it was very simple to undef Info{'pid'} in ServerShutdown and
that seems to have solved my problem.

I don't think this will create other problems, it was fine in my
"minimal testing".

BackupPC checks for an existing process by doing a kill(0, oldPid):

if ( $Info{pid} ne "" && kill(0, $Info{pid}) ) {
print(STDERR $bpc->timeStamp,
"Another BackupPC is running (pid $Info{pid}); quitting...\n");
exit(1);
}

kill(0, oldPid) doesn't actually send a signal - it just returns a
status whether oldPid exists or not. So I'm surprised this test
doesn't work correctly - perhaps some other process was started
with the same pid that BackupPC used to have?

Here is a simple patch.

Thanks. I'm ok adding the patch - it's safe to remove the pid before
quitting.

BTW, does BackupPC_nightly run cleanly now?

Craig


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
_______________________________________________
BackupPC-users mailing list
BackupPC-users < at > lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/backuppc-users
http://backuppc.sourceforge.net/

Quoting Craig Barratt <cbarratt < at > users.sourceforge.net>:

Tony Nelson writes:

I found it was very simple to undef Info{'pid'} in ServerShutdown and
that seems to have solved my problem.


[snip]

kill(0, oldPid) doesn't actually send a signal - it just returns a
status whether oldPid exists or not. So I'm surprised this test
doesn't work correctly - perhaps some other process was started
with the same pid that BackupPC used to have?


That's exactly what it was.. it just wasn't a BackupPC process.. it was usually
a httpd (not that what kind it was really matters)

Here is a simple patch.

Thanks. I'm ok adding the patch - it's safe to remove the pid before
quitting.

BTW, does BackupPC_nightly run cleanly now?


It seems to have run cleanly since I restarted BackupPC with my (other) patch.
I'm not sure why I would have had to restart it, but that seem to have gotten
it done.

Tony


This email message from Starpoint Solutions LLC is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. Opinions, conclusions and other information in this message that do not relate to the official business of Starpoint Solutions shall be understood as neither given nor endorsed by it.