Then look for a configuration error. I doubt there is a problem with Cfengine 
itself.
Use -v on both sides to debug

M

Seva Gluschenko wrote:
> Mark,
> 
> both server and clients were cfengine-community-3.0.4p2-1.centos5.i386.rpm.
> 
> Now server is running cfengine-community-3.0.5-b1.i386.rpm, built from
> the source. I've configured one of clients for the package update, so
> will see whether it helps. It would be really helpful to have a chance
> to know the moment when ipaddr becomes empty.
> 
> 2010/5/31 Mark Burgess <mark.burg...@iu.hio.no>:
>> Could be - depends what the clients were before. I am not seeing this kind 
>> of error.
>> Usually it is a case of error in the policy that is difficult to see.
>>
>> M
>>
>> Seva Gluschenko wrote:
>>> Mark,
>>>
>>> Just updated to rev. 1027. If you could be so kind and add EDEADLK
>>> acknowledgment to transation.c (the patch I've sent), that would help
>>> some Linux systems users, I believe.
>>>
>>> At the first glance, the message is still there:
>>>
>>> May 31 16:56:20 xxx cf-serverd[14666]:  Denying connection from
>>> non-authorized IP
>>>
>>> Does it mean all clients must be upgraded to 3.0.5b1 as well to get rid of 
>>> this?
>>>
>>> 2010/5/31 Mark Burgess <mark.burg...@iu.hio.no>:
>>>> 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
>>>> -------------------------------------------------
>>>>
>>>
>>>
>> --
>> 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
-------------------------------------------------
_______________________________________________
Help-cfengine mailing list
Help-cfengine@cfengine.org
https://cfengine.org/mailman/listinfo/help-cfengine

Reply via email to