Bug 132680 - updating ccsd with cluster file <= in memory, results in original known file on that node
updating ccsd with cluster file <= in memory, results in original known file ...
Product: Red Hat Cluster Suite
Classification: Red Hat
Component: gfs (Show other bugs)
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Jonathan Earl Brassow
GFS Bugs
Depends On:
  Show dependency treegraph
Reported: 2004-09-15 15:10 EDT by Corey Marthaler
Modified: 2010-01-11 21:58 EST (History)
0 users

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

Attachments (Terms of Use)

  None (edit)
Description Corey Marthaler 2004-09-15 15:10:13 EDT
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 15:26:24 EDT
I can't reproduce this...

What version of xml lib are you running?

> xml2-config --version
Comment 2 Corey Marthaler 2004-09-15 15:28:01 EDT
same version: 
[root@morph-01 root]#  xml2-config --version 
Comment 3 Jonathan Earl Brassow 2004-09-15 16:48:03 EDT
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 16:54:30 EDT
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 17:04:05 EDT
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 18:08:49 EDT

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 18:45:29 EDT
fix verified. 
Comment 8 Kiersten (Kerri) Anderson 2004-11-16 14:13:29 EST
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.