[BlueOnyx:03065] Re: CCED problem?

David Booth md at goulburn.net.au
Wed Dec 9 18:14:55 -05 2009


On 10/12/2009, at 9:42 AM, Michael Stauber wrote:

> Hi Jason,
>
>> Posted too soon, I found the error. The output is;
>>
>> 1-448,450-456,459-505,507-594,596,598,600,604-609,620-621,623 
>> -641,645,647,6
>> 52,656-658,669-674,697,699,701
>>
>> /usr/sausalito/codb/codb.oids reports:
>> 1-447,450-456,459-505,508-590,604-609,620-621,623 
>> -640,645,647,652,656-658,6
>> 69-674,697,699,701
>
> Ok, it appears that the following CODB objects are causing conflicts:
>
> /usr/sausalito/codb/objects/448
> /usr/sausalito/codb/objects/507
> /usr/sausalito/codb/objects/591
> /usr/sausalito/codb/objects/592
> /usr/sausalito/codb/objects/593
> /usr/sausalito/codb/objects/594
> /usr/sausalito/codb/objects/596
> /usr/sausalito/codb/objects/597
> /usr/sausalito/codb/objects/598
> /usr/sausalito/codb/objects/600
> /usr/sausalito/codb/objects/641
>
> They are physically present on the file system, but are not listed in
> /usr/sausalito/codb/codb.oids, which lists all the CODB objects that  
> CODB
> "knows" about.
>
> At this point I'd suggest to (re)move those objects. To safely do so,  
> do this,
> one would do this (but read on before you actually do it!):
>
> /etc/init.d/crond stop
> /etc/init.d/cced.init stop
> rm -R /usr/sausalito/codb/objects/448
> rm -R /usr/sausalito/codb/objects/507
> rm -R /usr/sausalito/codb/objects/591
> rm -R /usr/sausalito/codb/objects/592
> rm -R /usr/sausalito/codb/objects/593
> rm -R /usr/sausalito/codb/objects/594
> rm -R /usr/sausalito/codb/objects/596
> rm -R /usr/sausalito/codb/objects/597
> rm -R /usr/sausalito/codb/objects/598
> rm -R /usr/sausalito/codb/objects/600
> rm -R /usr/sausalito/codb/objects/641
> /etc/init.d/crond start
> /etc/init.d/cced.init start
>
> BUT (!!!): At the time I write this your CODB objects might already  
> have seen
> some changes. So to be safe, do this:
>
> First of all we create a backup copy of /usr/sausalito/codb/ and  
> everything
> within:
>
> /etc/init.d/crond stop
> /etc/init.d/cced.init stop
> tar czvf /root/codb.tar.gz /usr/sausalito/codb/
>
> Then run the script again that you created earlier. Compare the first  
> set of
> numbers with the second one. Delete any numbered directory in
> /usr/sausalito/codb/objects/ that doesn't show up in the 2nd set of  
> numbers
> that the script reported. Afterwards restart crond and cced.init.
>
> That should fix it. Just be REALLY sure you do not delete any numbered
> directory that's listed in /usr/sausalito/codb/codb.oids, as that will  
> have
> ill side effects.
>
> If this sounds too complicated, or you're worried that you may break
> something, then please contact me offlist and I'll do it for you.
>
> -- 
> With best regards
>
> Michael Stauber

Hi Michael, Jason,

I've been grappling with this of late, with Greg's help.
It's happened several times on one bx vps and once on another.

The first time I/we manually created codb.oids to match the intervals  
in objects - painful, and prone to error.

Since then I have restored functionality by:

	service cced.init stop

	ls /usr/sausalito.codb/ | sort -n

Remember the last (highest) number - call it X

edit /usr/sausalito/codb/codb.oids

Replace whatever's there with

	1-X

(I mean literally "1-X" - not one minus X)

	service cced.init start

That gets me out of jail - until the next time....

Safer than deleting objects. In fact I've seen codb.oids containing  
some very odd intervals, highly inconsistent with what's in ls objects.
There was one time when codb.oids said something like 1-1000 but  
objects contained over 3000
This makes me think that it is the writing out of codb.oids by whatever  
auditing processes cced is doing periodically that is at fault, not the  
existence or otherwise of objects.
  I'd be reluctant to delete objects on the basis of what codb.oids says.

I'm considering, if it happens again, to use that script (without the  
last 4 lines) and > /usr/sausalito/codb/codb.oids

Then service cced.init restart

I'm treading water until the cause is dug up and, hopefully, removed.

David Booth




More information about the Blueonyx mailing list