[Bacula-bugs] [bacula 0000797]: bacula-fd (maybe other daemons) fails to restart if happens to have same pid as at last reboot

[<bac...@li...>]

The following issue requires your FEEDBACK. 
====================================================================== 
http://bugs.bacula.org/view.php?id=797 
====================================================================== 
Reported By:                lcdadmin
Assigned To:                
====================================================================== 
Project:                    bacula
Issue ID:                   797
Category:                   File Daemon
Reproducibility:            sometimes
Severity:                   minor
Priority:                   normal
Status:                     feedback
====================================================================== 
Date Submitted:             03-05-2007 16:33 EST
Last Modified:              03-07-2007 08:53 EST
====================================================================== 
Summary:                    bacula-fd (maybe other daemons) fails to restart if
happens to have same pid as at last reboot
Description: 
The file daemon has failed to start up when we reboot some of our old SGI
workstations.  A co-worker suggested the problem might be leftover pid
files, but I saw that the create_pid_file() function in src/lib/bsys.c
sends a signal to the pid it finds in any old pid files, so I dismissed
that suggestion.

By turning on a higher level of debugging, I discovered that my coworker
was right. The IRIX reboots are sufficiently deterministic that bacula-fd
is starting up with the same pid as it had on the last reboot:

 Feb 27 08:34:55 6W:aufbau root[549]: aufbau-fd: backup.c:111 end
blast_data ok=1
 Feb 27 08:34:55 6W:aufbau root[549]: aufbau-fd: job.c:208 Quit command
loop. Canceled=0
 Feb 27 08:34:55 6W:aufbau root[549]: aufbau-fd: job.c:289 Calling
term_find_files
 Feb 27 12:39:59 6W:aufbau root[549]: Starting the Bacula File daemon
 Feb 27 12:40:01 6W:aufbau root[549]: bacula-fd: filed_conf.c:380
Inserting director res: grendel-mon
 Feb 27 12:40:01 6W:aufbau root[549]: bacula-fd: filed_conf.c:380
Inserting director res: grendel-mon
 Feb 27 12:40:01 6W:aufbau root[549]: 27-Feb 12:40 aufbau-fd: ERROR
TERMINATION at bsys.c:433
 Feb 27 12:40:01 6W:aufbau root[549]: bacula-fd is already running.
pid=632
 Feb 27 12:40:01 6W:aufbau root[549]: Check file
/var/run/bacula-fd.9102.pid

Notice that the reporting pid (549) is the same before and after the
reboot (it doesn't match the reported pid=632 because 549 is the pid of
the logger process shunting bacula-fd's stderr to syslog, rather than that
of bacula-fd itself.


====================================================================== 

---------------------------------------------------------------------- 
 lcdadmin - 03-05-07 16:35  
---------------------------------------------------------------------- 
I forgot to mention that, while I am running 1.38.11, I looked at the copy
of bsys.c in the subversion repository, and I think the current code would
still fail  to restart if the rebooted daemon has the same pid as on the
previous reboot. 

---------------------------------------------------------------------- 
 kern - 03-07-07 08:53  
---------------------------------------------------------------------- 
>From what I see, you patch defeats the purpose of a pid file, and will
permit two Bacula to run at the same time.  Perhaps I am missing
something. If so, please explain ...

The root of the problem seems to be that your system is not configured
correctly for the following two reasons:

1. When shutting down a system normally, Bacula should be properly
shutdown and will remove the pid file (or at least invalidate it -- I
haven't looked at the code for 7 years).  If this is not the case on your
system, you need to fix it.

2. Any system that assigns predictable pids is subject to lots of security
problems and should be fixed. 

Item 1 is the root of the problems.  Item 2 is rather secondary IMO.

 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
03-05-07 16:33  lcdadmin       New Issue                                    
03-05-07 16:35  lcdadmin       Note Added: 0002288                          
03-07-07 08:53  kern           Note Added: 0002290                          
03-07-07 08:53  kern           Status                   new => feedback     
======================================================================