Sorry, patched the threading for something unrelated. Could be a conflict. Try 
new svn


Seva Gluschenko wrote:
> Now it seems like I like talking to myself ;>
> 
> Anyway, I've looked further and found that error code 35 stands for
> EDEADLK which wasn't obviously meant by pthread_mutex_trylock manual
> page authors, but it states for sure that the mutex is locked. So I've
> patched transaction.c a bit to handle it. The patch is as follows:
> 
> --- src/transaction.c.orig      2010-05-31 15:22:16.317657266 +0400
> +++ src/transaction.c   2010-05-31 15:22:57.226673209 +0400
> @@ -439,7 +439,7 @@
> 
>   status = pthread_mutex_trylock(mutex);
> 
> - if(status != EBUSY)
> + if (status != EBUSY && status != EDEADLK)
>     {
>       CfOut(cf_error, "", "!! The mutex %d was not locked in %s() --
> status=%d", name, fname, status);
>       FatalError("Software assertion failure\n");
> 
> The new caveat which have been discovered can be best illustrated by
> the following string:
> 
> May 31 15:31:25 xxx cf-serverd[19810]:  Denying connection from
> non-authorized IP
> 
> as far as I've got from sources, the IP address must be listed in this
> message, so in short we have an IP leak somewhere.
> 
> 2010/5/31 Seva Gluschenko <seva.glusche...@gmail.com>:
>> Well, after certain research I've finally built the Cfengine RPM with
>> bison. Unfortunately I've got no success, because Cfengine is
>> complaining upon startup:
>>
>> # /etc/init.d/cfengine3 start
>> Starting cfengine3 ...
>> !! The mutex 6 was not locked in PromiseIdExists() -- status=35
>> Fatal cfengine error: Software assertion failure
>> cf-agent was not able to get confirmation of promises from
>> cf-promises, so going to failsafe
>> cf-execd started.                               [OK]
>> !! The mutex 6 was not locked in PromiseIdExists() -- status=35
>> Fatal cfengine error: Software assertion failure
>> cf-agent was not able to get confirmation of promises from
>> cf-promises, so going to failsafe
>> cf-serverd started.                             [OK]
>>
>> So that I've been forced to roll back to 3.0.4p2 and still getting
>> multiple client connection errors now. Any help would be appreciated
>> much.
>>
>> 2010/5/28 Seva Gluschenko <seva.glusche...@gmail.com>:
>>> Thank you for pointing this out. Bison wasn't installed indeed.
>>>
>>> By the way, copying /usr/bin/libtool didn't help until I copied
>>> ltmain.sh and missing from /usr/share/libtool as well. Now I've been
>>> able to compile cfengine, but RPM packaging issues are still demanding
>>> to be solved. Working on it.
>>>
>>> 2010/5/28 Mark Burgess <mark.burg...@iu.hio.no>:
>>>> Install bison
>>>>
>>>> Seva Gluschenko wrote:
>>>>> Unfortunately, things went wrong much further than I estimated. After
>>>>> installation from the home directory with plain make install I've got
>>>>> the following error:
>>>>>
>>>>> cf3:/var/cfengine/inputs/groups.cf:441,12: yacc stack overflow, near 
>>>>> token ','
>>>>>
>>>>> well, my groups definition contain quite long "or" lists because it
>>>>> was the only way I've found to have a chance to define server groups.
>>>>> Now I rolled back to cfengine-community 3.0.4p2 from RPM since it
>>>>> doesn't have yacc stack overflows. Is there any method to increase its
>>>>> stack at the build time?
>>>>>
>>>>> 2010/5/28 Mark Burgess <mark.burg...@iu.hio.no>:
>>>>>> Right - copy libtool from your system into the directory also
>>>>>>
>>>>>> cp /usr/bin/libtool .
>>>>>>
>>>>>> and try again (might need aclocal again)
>>>>>>
>>>>>> Seva Gluschenko wrote:
>>>>>>> Mark,
>>>>>>>
>>>>>>> Thank you for your helpful advice, the following worked:
>>>>>>>
>>>>>>> aclocal
>>>>>>> automake -a -c
>>>>>>> make
>>>>>>>
>>>>>>> But when I wrote cfengine.spec to build an RPM, build failed with the
>>>>>>> following output:
>>>>>>>
>>>>>>> if /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I.
>>>>>>> -I. -I. -I/usr/include/db4 -I/usr/include  -pthread  -g -O2
>>>>>>> -Wreturn-type -Wmissing-prototypes -Wuninitialized -pthread -g -O2
>>>>>>> -I/usr/include/db4 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -pthread
>>>>>>> -g -O2 -I/usr/include/db4 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
>>>>>>> -MT libpromises_la-cf3parse.lo -MD -MP -MF
>>>>>>> ".deps/libpromises_la-cf3parse.Tpo" -c -o libpromises_la-cf3parse.lo
>>>>>>> `test -f 'cf3parse.c' || echo './'`cf3parse.c; \
>>>>>>>       then mv -f ".deps/libpromises_la-cf3parse.Tpo"
>>>>>>> ".deps/libpromises_la-cf3parse.Plo"; else rm -f
>>>>>>> ".deps/libpromises_la-cf3parse.Tpo"; exit 1; fi
>>>>>>> ../libtool: line 466: CDPATH: command not found
>>>>>>> ../libtool: line 1144: func_opt_split: command not found
>>>>>>> libtool: Version mismatch error.  This is libtool 2.2.6, but the
>>>>>>> libtool: definition of this LT_INIT comes from an older release.
>>>>>>> libtool: You should recreate aclocal.m4 with macros from libtool 2.2.6
>>>>>>> libtool: and run autoconf again.
>>>>>>> make[2]: *** [libpromises_la-cf3parse.lo] Error 1
>>>>>>>
>>>>>>> any ideas how to get rid of this? It hadn't happened upon plain build
>>>>>>> in the home directory.
>>>>>>>
>>>>>>> 2010/5/28 Mark Burgess <mark.burg...@iu.hio.no>:
>>>>>>>> Ah this is the perennial problem with these snapshots
>>>>>>>>
>>>>>>>> Run
>>>>>>>>
>>>>>>>> ./aclocal
>>>>>>>> make
>>>>>>>>
>>>>>>>> If that doesn't work, try
>>>>>>>>
>>>>>>>> ./aclocal
>>>>>>>> automake -a -c
>>>>>>>> make
>>>>>>>>
>>>>>>>> Seva Gluschenko wrote:
>>>>>>>>> Mark,
>>>>>>>>>
>>>>>>>>> I'm experiencing problems trying to build the latest svn on CentOS5.
>>>>>>>>> First of all, there's no automake 1.10 in RPM available, so I've
>>>>>>>>> patched configure script downgrading version to 1.9. Even though, make
>>>>>>>>> fails with the following output:
>>>>>>>>>
>>>>>>>>> $ cd . && /bin/sh /tmp/cfengine-3.0.5/missing --run automake-1.9 --gnu
>>>>>>>>> src/Makefile.am:8: Libtool library used but `LIBTOOL' is undefined
>>>>>>>>> src/Makefile.am:8:
>>>>>>>>> src/Makefile.am:8: The usual way to define `LIBTOOL' is to add 
>>>>>>>>> `AC_PROG_LIBTOOL'
>>>>>>>>> src/Makefile.am:8: to `configure.ac' and run `aclocal' and `autoconf' 
>>>>>>>>> again.
>>>>>>>>> src/Makefile.am: required file `./compile' not found
>>>>>>>>> WARNING: `automake-1.9' is needed, and you do not seem to have it 
>>>>>>>>> handy on your
>>>>>>>>>          system.  You might have modified some files without having 
>>>>>>>>> the
>>>>>>>>>          proper tools for further handling them.  Check the `README' 
>>>>>>>>> file,
>>>>>>>>>          it often tells you about the needed prerequirements for 
>>>>>>>>> installing
>>>>>>>>>          this package.  You may also peek at any GNU archive site, in 
>>>>>>>>> case
>>>>>>>>>          some other package would contain this missing `automake-1.9' 
>>>>>>>>> program.
>>>>>>>>> make: *** [Makefile.in] Error 1
>>>>>>>>>
>>>>>>>>> Despite LIBTOOL is defined in configure and present in the tree. I've
>>>>>>>>> tried to switch to the system-wide libtool but got no success. At this
>>>>>>>>> point I'm stuck. Is there any change to get some early RPM build for
>>>>>>>>> CentOS5? We've already faced problems with servers which weren't
>>>>>>>>> managed until they keys were removed from the master server because of
>>>>>>>>> bad key issue.
>>>>>>>>>
>>>>>>>>> 2010/5/28 Mark <m...@iu.hio.no>:
>>>>>>>>>> Try the latest svn in case some recent changes could affect this. 
>>>>>>>>>> Just a
>>>>>>>>>> suggestion.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Mark
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 27 May 2010, at 13:06, Seva Gluschenko 
>>>>>>>>>> <seva.glusche...@gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hello folks,
>>>>>>>>>>>
>>>>>>>>>>> There's an error report which happens on regular basis since a 
>>>>>>>>>>> number
>>>>>>>>>>> of managed servers grew to 100+:
>>>>>>>>>>>
>>>>>>>>>>> BAD: keys did not match
>>>>>>>>>>> !! Authentication dialogue with X.X.X.X failed
>>>>>>>>>>>
>>>>>>>>>>> I'm virtually sure that there're no hijacking attempts in my 
>>>>>>>>>>> network,
>>>>>>>>>>> so I suppose that happens because of some server limitations. I rose
>>>>>>>>>>> initial maxchildren setting from 1000 to 5000 in body server 
>>>>>>>>>>> control,
>>>>>>>>>>> but it doesn't seem to have effect. Any ideas?
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> SY, Seva Gluschenko.
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> Help-cfengine mailing list
>>>>>>>>>>> Help-cfengine@cfengine.org
>>>>>>>>>>> https://cfengine.org/mailman/listinfo/help-cfengine
>>>>>>>> --
>>>>>>>> Mark Burgess
>>>>>>>>
>>>>>>>> -------------------------------------------------
>>>>>>>> Professor of Network and System Administration
>>>>>>>> Oslo University College, Norway
>>>>>>>>
>>>>>>>> Personal Web: http://www.iu.hio.no/~mark
>>>>>>>> Office Telf : +47 22453272
>>>>>>>> -------------------------------------------------
>>>>>>>>
>>>>>>>
>>>>>> --
>>>>>> Mark Burgess
>>>>>>
>>>>>> -------------------------------------------------
>>>>>> Professor of Network and System Administration
>>>>>> Oslo University College, Norway
>>>>>>
>>>>>> Personal Web: http://www.iu.hio.no/~mark
>>>>>> Office Telf : +47 22453272
>>>>>> -------------------------------------------------
>>>>>>
>>>>>
>>>>>
>>>> --
>>>> Mark Burgess
>>>>
>>>> -------------------------------------------------
>>>> Professor of Network and System Administration
>>>> Oslo University College, Norway
>>>>
>>>> Personal Web: http://www.iu.hio.no/~mark
>>>> Office Telf : +47 22453272
>>>> -------------------------------------------------
>>>>
>>>
>>>
>>> --
>>> SY, Seva Gluschenko.
>>>
>>
>>
>> --
>> SY, Seva Gluschenko.
>>
> 
> 
> 

-- 
Mark Burgess

-------------------------------------------------
Professor of Network and System Administration
Oslo University College, Norway

Personal Web: http://www.iu.hio.no/~mark
Office Telf : +47 22453272
-------------------------------------------------
_______________________________________________
Help-cfengine mailing list
Help-cfengine@cfengine.org
https://cfengine.org/mailman/listinfo/help-cfengine

Reply via email to