Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Linux-HA: Users

weird problem w/ R1

 

 

Linux-HA users RSS feed   Index | Next | Previous | View Threaded


dmaziuk at bmrb

May 2, 2012, 4:25 PM

Post #1 of 3 (284 views)
Permalink
weird problem w/ R1

Hi everyone,

I must be overlooking something obvious... I have a simple haresources
setup with

node drbddisk::sessdata Filesystem::/dev/drbd0::/raid::ext3::rw \
ip.addr httpd xinetd pure_ftpd pure_uploadscript bacula-client mon

bacula-client is in /etc/ha.d/resource.d, it's a copy of stock
/etc/init.d/bacula-fd with config, lock, and pid file changed to make it
listen on a non-standard port: this is for backing up drbd filesystem
(there's the standard bacula client running also).

bacula-client doesn't start. I added a couple of 'logger' lines and if I
manually run "/etc/ha.d/resource.d/bacula-client start ; echo $?" I get
0 and the log:
node logger: starting bacula-fd -c /etc/bacula/deposit-fd.conf
node logger: bacula-fd -c /etc/bacula/deposit-fd.conf running

Yet on failover I get this:

node ResourceManager[3734]: info: Running /etc/init.d/httpd start
node ResourceManager[3734]: info: Running /etc/init.d/xinetd start
node ResourceManager[3734]: info: Running /etc/ha.d/resource.d/pure_ftpd
start
node xinetd[4204]: xinetd Version 2.3.14 started with libwrap loadavg
labeled-networking options compiled in.
node xinetd[4204]: Started working: 1 available service
node ResourceManager[3734]: info: Running
/etc/ha.d/resource.d/pure_uploadscript start
node ResourceManager[3734]: info: Running /etc/init.d/mon start

It doesn't seem to run that particular script: it starts
pure_uploadscript from resource.d and mon from init.d, but not the one
in between. What's weird is I now have it happening on 2 clusters:
centos 5 w/ heartbeat 2.1.4, and centos 6 w/ heartbeat 3.0.4. The only
common thing is bacula version: 5.

Any ideas?

TIA
--
Dimitri Maziuk
Programmer/sysadmin
BioMagResBank, UW-Madison -- http://www.bmrb.wisc.edu
Attachments: signature.asc (0.25 KB)


dejanmm at fastmail

May 9, 2012, 5:07 AM

Post #2 of 3 (262 views)
Permalink
Re: weird problem w/ R1 [In reply to]

Hi,

On Wed, May 02, 2012 at 06:25:55PM -0500, Dimitri Maziuk wrote:
> Hi everyone,
>
> I must be overlooking something obvious... I have a simple haresources
> setup with
>
> node drbddisk::sessdata Filesystem::/dev/drbd0::/raid::ext3::rw \
> ip.addr httpd xinetd pure_ftpd pure_uploadscript bacula-client mon
>
> bacula-client is in /etc/ha.d/resource.d, it's a copy of stock
> /etc/init.d/bacula-fd with config, lock, and pid file changed to make it
> listen on a non-standard port: this is for backing up drbd filesystem
> (there's the standard bacula client running also).
>
> bacula-client doesn't start. I added a couple of 'logger' lines and if I
> manually run "/etc/ha.d/resource.d/bacula-client start ; echo $?" I get
> 0 and the log:
> node logger: starting bacula-fd -c /etc/bacula/deposit-fd.conf
> node logger: bacula-fd -c /etc/bacula/deposit-fd.conf running
>
> Yet on failover I get this:
>
> node ResourceManager[3734]: info: Running /etc/init.d/httpd start
> node ResourceManager[3734]: info: Running /etc/init.d/xinetd start
> node ResourceManager[3734]: info: Running /etc/ha.d/resource.d/pure_ftpd
> start
> node xinetd[4204]: xinetd Version 2.3.14 started with libwrap loadavg
> labeled-networking options compiled in.
> node xinetd[4204]: Started working: 1 available service
> node ResourceManager[3734]: info: Running
> /etc/ha.d/resource.d/pure_uploadscript start
> node ResourceManager[3734]: info: Running /etc/init.d/mon start
>
> It doesn't seem to run that particular script: it starts
> pure_uploadscript from resource.d and mon from init.d, but not the one
> in between. What's weird is I now have it happening on 2 clusters:
> centos 5 w/ heartbeat 2.1.4, and centos 6 w/ heartbeat 3.0.4. The only
> common thing is bacula version: 5.
>
> Any ideas?

No, but you can add set -x in some places in ResourceManager and
see what gives.

Thanks,

Dejan

> TIA
> --
> Dimitri Maziuk
> Programmer/sysadmin
> BioMagResBank, UW-Madison -- http://www.bmrb.wisc.edu
>



> _______________________________________________
> Linux-HA mailing list
> Linux-HA [at] lists
> http://lists.linux-ha.org/mailman/listinfo/linux-ha
> See also: http://linux-ha.org/ReportingProblems

_______________________________________________
Linux-HA mailing list
Linux-HA [at] lists
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems


dmaziuk at bmrb

May 18, 2012, 11:59 AM

Post #3 of 3 (245 views)
Permalink
Re: weird problem w/ R1 [In reply to]

On 05/09/2012 07:07 AM, Dejan Muhamedagic wrote:
> Hi,
>
> On Wed, May 02, 2012 at 06:25:55PM -0500, Dimitri Maziuk wrote:
>>
[heartbeat] doesn't seem to run that particular script: it starts
>> pure_uploadscript from resource.d and mon from init.d, but not the one
>> in between. What's weird is I now have it happening on 2 clusters:
>> centos 5 w/ heartbeat 2.1.4, and centos 6 w/ heartbeat 3.0.4. The only
>> common thing is bacula version: 5.
>>
>> Any ideas?
>
> No, but you can add set -x in some places in ResourceManager and
> see what gives.

Not very useful on 2.1: it prints out the very 1st resource (drbd fs)
and stops there. And all that goes to the console, not to the log --
it's a good thing I have these boxes hooked up to a terminal server.

However, it did (eventually) lead me to "status)" case in my
bacula-client startup script: I forgot to change "status $prog" to
"status -p $pidfile $prog". So it was reporting bacula-fd as already
running -- correctly, since there's already an instance listening on the
standard port. It just wasn't the right instance.

Thanks Dejan for pointing me in the right direction.

--
Dimitri Maziuk
Programmer/sysadmin
BioMagResBank, UW-Madison -- http://www.bmrb.wisc.edu
Attachments: signature.asc (0.25 KB)

Linux-HA users RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.