[BlueOnyx:03144] Re: CCED problem?

rordonez at xnet.mx rordonez at xnet.mx
Mon Dec 21 15:05:20 -05 2009



-----Original Message-----
From: blueonyx-bounces at blueonyx.it [mailto:blueonyx-bounces at blueonyx.it] On
Behalf Of David Booth
Sent: Miércoles, 09 de Diciembre de 2009 04:15
To: BlueOnyx General Mailing List
Subject: [BlueOnyx:03065] Re: CCED problem?

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

_______________________________________________
Blueonyx mailing list
Blueonyx at blueonyx.it
http://www.blueonyx.it/mailman/listinfo/blueonyx
=====================================================

Happened to me , After a slooow cmu import.

Just in case someone has this problem, the post is missing some slashes 

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

#metodo de desincronizacion de Ids de Objeto
#Stop cced first
/etc/init.d/cced.init stop

#find the last (highest object number) 
ls /usr/sausalito/codb/objects | sort -n

#edit the file that hsould contain this number
pico /usr/sausalito/codb/codb.oids

#REPLACE THE STRING INSIDE WITH 1-HIGHEST NUMBER ie: 1-4471

#start cced again
/etc/init.d/cced.init start 



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






More information about the Blueonyx mailing list