Bug 132680 - updating ccsd with cluster file <= in memory, results in original known file on that node
Summary: updating ccsd with cluster file <= in memory, results in original known file ...
Alias: None
Product: Red Hat Cluster Suite
Classification: Retired
Component: gfs   
(Show other bugs)
Version: 4
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Jonathan Earl Brassow
QA Contact: GFS Bugs
Depends On:
TreeView+ depends on / blocked
Reported: 2004-09-15 19:10 UTC by Corey Marthaler
Modified: 2010-01-12 02:58 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-09-16 22:45:29 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Corey Marthaler 2004-09-15 19:10:13 UTC
Description of problem:
An update of ccsd with a cluster.conf version that is equal to or less
than the current verion in memory, that node will revert all the way
back to version "1" (or what ever version the original file was) and
be out of sync with the rest of the cluster which is left at the
current verion in memory.

Version-Release number of selected component (if applicable):

How reproducible:

Expected Results:  It should just fail, keep the current verion in
memory, and write out a reject file for the one attempting to update

Comment 1 Jonathan Earl Brassow 2004-09-15 19:26:24 UTC
I can't reproduce this...

What version of xml lib are you running?

> xml2-config --version

Comment 2 Corey Marthaler 2004-09-15 19:28:01 UTC
same version: 
[root@morph-01 root]#  xml2-config --version 

Comment 3 Jonathan Earl Brassow 2004-09-15 20:48:03 UTC
Ok, in order to reproduce this you need to do the following:

all> ccsd
all> cman_tool join
one> inc by 2 config_version of cluster.conf
one> killall -HUP ccsd
two> dec by 1 config_version of cluster.conf
two> killall -HUP ccsd
two> observe bug

Doing all the single node steps on a specific machine will not cause the bug.  
Please verify that this is true.

Comment 4 Corey Marthaler 2004-09-15 20:54:30 UTC
You do not have to inc the version by 2, any bump in the version will
work. Also you don't have to dec by one, you just have to send ccsd a
-HUP with a version equal to or less then what's currently in mem.

Also, when it goes back to the original version, it is just that. All
changes that may have been made to the file when updated previously
are lost.

Comment 5 Corey Marthaler 2004-09-15 21:04:05 UTC
You are correct in that doing all the single node steps on a specific
machine will not cause the bug.

Comment 6 Jonathan Earl Brassow 2004-09-15 22:08:49 UTC

The second node was not reading the new file into memory until it was
needed, this offered a window of time to change the file before it
could be read.

This cause two types of bugs.  The first (this one) was that if the
file was changed and an update was attempted, a failure of that update
would result in the in-memory (stale) copy being written to disk.

The second bug that this could cause is if the file was changed on
disk before it was read into memory, nodes could become out of sync.

Comment 7 Corey Marthaler 2004-09-16 22:45:29 UTC
fix verified. 

Comment 8 Kiersten (Kerri) Anderson 2004-11-16 19:13:29 UTC
Updating version to the right level in the defects.  Sorry for the storm.

Note You need to log in before you can comment on or make changes to this bug.