Re: Strange behavioural differences when invoking cfengine through cfrun

[Mark Burgess]

I am not sure that I have ever received this patch, or recall the
problem, but I shall look into it now. Next cfengine release will be
beginning of April (not the 1st!)

Mark

On Wed, 2005-03-09 at 14:26 -0600, rader@ginseng.hep.wisc.edu wrote:
> This appears to be the bug I described to the bug-cfengine@gnu.org
> list a few weeks ago.  Refer to
> 
>  Subject: cfpclose() or "packages: under cfrun only" bug on RHEL3?
>  Subject: fix for a bug in cfservd v2.1.11 
> 
> A patch that shows up the problem...
> 
>  cfrun somehost -- -qv | grep SRDEBUG
> 
> and a patch that fixes the problem follow.
> 
> Mark has not mentioned if he's going to fix this problem.  (I sure
> hope he does--as is, packages and processes actions via cfrun do
> not work on RHEL3 with cfengine 2.1.11 or better!)
> 
> steve 
> - - - 
> systems & network manager
> high energy physics
> university of wisconsin
> 
>  > ---- Original Message ----
>  > From: Eric Dorland
>  > Hello,
>  > 
>  > I'm attempting to roll out cfengine to a bunch of our servers (and more
>  > to come). I'm finally grokking everything, but I've run into one last
>  > problem I can't seem to solve. I've got a setup with all my master files
>  > are in a CVS repository. Cfagent pulls the files out of cvs whenever it
>  > updates. I also have a script to run cfrun everytime I commit something
>  > to the CVS repo. 
>  > 
>  > My problem is that cfagent is behaving differently when invoked from
>  > cfrun than it's periodic runs from cfexecd. The periodic runs through
>  > cfexecd work great. When I invoke cfrun however, the "packages" target
>  > doesn't work. I have cfengine check to see if the ntp package is
>  > installed. If it isn't it installs it using up2date. I know the ntp
>  > package is installed, but whenever I invoke cfagent through cfrun the
>  > packages target says it's not installed. When run through cfexecd
>  > everything works as expected.
>  > 
>  > I hope that was clear. I'm running the latest 2.1.13 on RHEL3. Has
>  > anyone seen a similar problem? (Googling didn't come up with anything
>  > similar). Let me know any debugging output I could provide that would be
>  > helpful. Thanks.
>  > 
>  > -- 
>  > Eric Dorland
>  > eric.dorland@mcgill.ca
>  > WSG
>  > 514.398-5023 ext. 09562
>  > 
>  > 
>  > 
>  > _______________________________________________
>  > Help-cfengine mailing list
>  > Help-cfengine@gnu.org
>  > http://lists.gnu.org/mailman/listinfo/help-cfengine
> 
> 
> --- popen.c.orig        2005-02-22 15:10:40.000000000 -0600
> +++ popen.c     2005-02-24 16:33:51.000000000 -0600
> @@ -51,6 +51,7 @@
>     FILE *pp = NULL;
>  
>   Debug("cfpopen(%s)\n",command);
> +Verbose("SRDEBUG: cfpopen(%s)\n",command);
>  
>   if ((*type != 'r' && *type != 'w') || (type[1] != '\0'))
>      {
> @@ -632,6 +633,7 @@
>     {
>     if (errno != EINTR)
>        {
> +Verbose("SRDEBUG: cfpclose() failed: %s\n",strerror(errno)); 
>        return -1;
>        }
>     }
> 
> 
> --- popen.c.orig        2005-02-22 15:10:40.000000000 -0600
> +++ popen.c     2005-02-24 16:46:46.000000000 -0600
> @@ -51,6 +51,7 @@
>     FILE *pp = NULL;
>  
>   Debug("cfpopen(%s)\n",command);
> +Verbose("SRDEBUG: cfpopen(%s)\n",command);
>  
>   if ((*type != 'r' && *type != 'w') || (type[1] != '\0'))
>      {
> @@ -75,6 +76,9 @@
>      {
>      return NULL;
>      }
> +
> +/* HERE SR restoring default sig handler for SIGCHLD HERE */
> +signal(SIGCHLD,SIG_DFL);
>   
>   if (pid == 0)
>      {
> @@ -632,6 +636,7 @@
>     {
>     if (errno != EINTR)
>        {
> +Verbose("SRDEBUG: cfpclose() failed: %s\n",strerror(errno)); 
>        return -1;
>        }
>     }
> 
> 
> 
> 
> 
> _______________________________________________
> Help-cfengine mailing list
> Help-cfengine@gnu.org
> http://lists.gnu.org/mailman/listinfo/help-cfengine