Re: [Gluster-devel] [Gluster-infra] Different version of run-tests.sh in jenkin slaves?

[Emmanuel Dreyfus]

On Thu, Jan 28, 2016 at 12:17:58PM +0530, Raghavendra Talur wrote:
> Where do I find config in NetBSD which decides which location to dump core
> in?

sysctl kern.defcorename for the default location and name. It can be
overriden per process using  sysctl proc.$$.corename

> Any particular reason you added /d/backends/*/*.core to list of path to
> search for core?

Yes, this is required for standard compliance of the exposed glusterfs
filesystem in the case of low system PATH_MAX. See in posix.c:

/*  
 * _XOPEN_PATH_MAX is the longest file path len we MUST 
 * support according to POSIX standard. When prepended
 * by the brick base path it may exceed backed filesystem
 * capacity (which MAY be bigger than _XOPEN_PATH_MAX). If
 * this is the case, chdir() to the brick base path and
 * use relative paths when they are too long. See also
 * MAKE_REAL_PATH in posix-handle.h   
  */  
_private->path_max = pathconf(_private->base_path, _PC_PATH_MAX);
if (_private->path_max != -1 &&   
_XOPEN_PATH_MAX + _private->base_path_length > _private->path_max) {
ret = chdir(_private->base_path); 
if (ret) {
gf_msg (this->name, GF_LOG_ERROR, 0,
P_MSG_BASEPATH_CHDIR_FAILED,
"chdir() to \"%s\" failed",
_private->base_path);
goto out;
}
And the core goes in current directory by default. We could use
sysctl(3) to change that if we need.


-- 
Emmanuel Dreyfus
m...@netbsd.org
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Gluster-infra] Different version of run-tests.sh in jenkin slaves?

[Emmanuel Dreyfus]

On Thu, Jan 28, 2016 at 12:17:58PM +0530, Raghavendra Talur wrote:
> Where do I find config in NetBSD which decides which location to dump core
> in?

I crafted the patch below, bbut it is probably much simplier to just
set kern.defcorename to /%n-%p.core on all VM slaves. I will do it.

diff --git a/xlators/storage/posix/src/posix.c 
b/xlators/storage/posix/src/posix.c
index 272d08f..2fd2d7d 100644
--- a/xlators/storage/posix/src/posix.c
+++ b/xlators/storage/posix/src/posix.c
@@ -29,6 +29,10 @@
 #include 
 #endif /* HAVE_LINKAT */
 
+#ifdef __NetBSD__
+#include 
+#endif /* __NetBSD__ */
+
 #include "glusterfs.h"
 #include "checksum.h"
 #include "dict.h"
@@ -6631,6 +6635,8 @@ init (xlator_t *this)
 _private->path_max = pathconf(_private->base_path, _PC_PATH_MAX);
 if (_private->path_max != -1 &&
 _XOPEN_PATH_MAX + _private->base_path_length > _private->path_max) 
{
+char corename[] = "/%n-%p.core";
+
 ret = chdir(_private->base_path);
 if (ret) {
 gf_msg (this->name, GF_LOG_ERROR, 0,
@@ -6639,7 +6645,15 @@ init (xlator_t *this)
 _private->base_path);
 goto out;
 }
+
 #ifdef __NetBSD__
+/* 
+ * Make sure cores go to the root and not in current 
+ * directory
+ */
+(void)sysctlbyname("proc.curproc.corename", NULL, NULL, 
+   corename, strlen(corename) + 1);
+
 /*
  * At least on NetBSD, the chdir() above uncovers a
  * race condition which cause file lookup to fail


-- 
Emmanuel Dreyfus
m...@netbsd.org
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Gluster-infra] Different version of run-tests.sh in jenkin slaves?

[Niels de Vos]

On Thu, Jan 28, 2016 at 12:00:41PM +0530, Raghavendra Talur wrote:
> Ok, RCA:
> 
> In NetBSD cores are being generated in /d/backends/*/*.core
> run-tests.sh looks only for "/core*" when looking for cores.
> 
> So, at the end of test run when regression.sh looks for core everywhere, it
> finds one and errors out.
> 
> Should think of a solution which is generic. Will update.

regression.sh is maintained on GitHub. All slaves should have this
repository checked out as /opt/qa. Please make sure any changes to this
script are pushed into the repo too:
https://github.com/gluster/glusterfs-patch-acceptance-tests/

Niels

> 
> 
> On Thu, Jan 28, 2016 at 11:37 AM, Raghavendra Talur 
> wrote:
> 
> >
> >
> > On Thu, Jan 28, 2016 at 11:17 AM, Atin Mukherjee 
> > wrote:
> >
> >> Are we running a different version of run-tests.sh in jenkin slaves. The
> >> reason of suspection is beacuse in last couple of runs [1] & [2] in
> >> NetBSD I am seeing no failures apart from bad tests but the regression
> >> voted failure and I can not make out any valid reason out of it.
> >>
> >> [1]
> >>
> >> https://build.gluster.org/job/rackspace-netbsd7-regression-triggered/13756/consoleFull
> >> [2]
> >>
> >> https://build.gluster.org/job/rackspace-netbsd7-regression-triggered/13755/consoleFull
> >
> >
> >
> > I checked the slave machine now.
> > regression.sh file is different but the run-tests.sh script is same.
> >
> > A wild guess here, is it possible that the core generation takes time and
> > when we check for a core right after a test is run it is not present yet?
> > Does anyone know how to work around that?
> >
> >
> >>
> >> ~Atin
> >> ___
> >> Gluster-infra mailing list
> >> gluster-in...@gluster.org
> >> http://www.gluster.org/mailman/listinfo/gluster-infra
> >>
> >
> >

> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel



signature.asc
Description: PGP signature
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Gluster-infra] Different version of run-tests.sh in jenkin slaves?

[Emmanuel Dreyfus]

On Thu, Jan 28, 2016 at 12:10:49PM +0530, Atin Mukherjee wrote:
> So does that mean we never analyzed any core reported by NetBSD
> regression failure? That's strange.

We got the cores from / but not from d/backends/*/ as I understand.

I am glad someone figured out the mystery. 

-- 
Emmanuel Dreyfus
m...@netbsd.org
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Gluster-infra] Different version of run-tests.sh in jenkin slaves?

[Raghavendra Talur]

On Thu, Jan 28, 2016 at 11:17 AM, Atin Mukherjee 
wrote:

> Are we running a different version of run-tests.sh in jenkin slaves. The
> reason of suspection is beacuse in last couple of runs [1] & [2] in
> NetBSD I am seeing no failures apart from bad tests but the regression
> voted failure and I can not make out any valid reason out of it.
>
> [1]
>
> https://build.gluster.org/job/rackspace-netbsd7-regression-triggered/13756/consoleFull
> [2]
>
> https://build.gluster.org/job/rackspace-netbsd7-regression-triggered/13755/consoleFull



I checked the slave machine now.
regression.sh file is different but the run-tests.sh script is same.

A wild guess here, is it possible that the core generation takes time and
when we check for a core right after a test is run it is not present yet?
Does anyone know how to work around that?


>
> ~Atin
> ___
> Gluster-infra mailing list
> gluster-in...@gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-infra
>
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Gluster-infra] Different version of run-tests.sh in jenkin slaves?

[Atin Mukherjee]

On 01/28/2016 12:00 PM, Raghavendra Talur wrote:
> Ok, RCA:
> 
> In NetBSD cores are being generated in /d/backends/*/*.core
> run-tests.sh looks only for "/core*" when looking for cores.
> 
> So, at the end of test run when regression.sh looks for core everywhere,
> it finds one and errors out.
So does that mean we never analyzed any core reported by NetBSD
regression failure? That's strange.
> 
> Should think of a solution which is generic. Will update.
> 
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Gluster-infra] Different version of run-tests.sh in jenkin slaves?

[Raghavendra Talur]

Ok, RCA:

In NetBSD cores are being generated in /d/backends/*/*.core
run-tests.sh looks only for "/core*" when looking for cores.

So, at the end of test run when regression.sh looks for core everywhere, it
finds one and errors out.

Should think of a solution which is generic. Will update.


On Thu, Jan 28, 2016 at 11:37 AM, Raghavendra Talur 
wrote:

>
>
> On Thu, Jan 28, 2016 at 11:17 AM, Atin Mukherjee 
> wrote:
>
>> Are we running a different version of run-tests.sh in jenkin slaves. The
>> reason of suspection is beacuse in last couple of runs [1] & [2] in
>> NetBSD I am seeing no failures apart from bad tests but the regression
>> voted failure and I can not make out any valid reason out of it.
>>
>> [1]
>>
>> https://build.gluster.org/job/rackspace-netbsd7-regression-triggered/13756/consoleFull
>> [2]
>>
>> https://build.gluster.org/job/rackspace-netbsd7-regression-triggered/13755/consoleFull
>
>
>
> I checked the slave machine now.
> regression.sh file is different but the run-tests.sh script is same.
>
> A wild guess here, is it possible that the core generation takes time and
> when we check for a core right after a test is run it is not present yet?
> Does anyone know how to work around that?
>
>
>>
>> ~Atin
>> ___
>> Gluster-infra mailing list
>> gluster-in...@gluster.org
>> http://www.gluster.org/mailman/listinfo/gluster-infra
>>
>
>
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Gluster-infra] Different version of run-tests.sh in jenkin slaves?

[Raghavendra Talur]

On Thu, Jan 28, 2016 at 12:10 PM, Atin Mukherjee 
wrote:

>
>
> On 01/28/2016 12:00 PM, Raghavendra Talur wrote:
> > Ok, RCA:
> >
> > In NetBSD cores are being generated in /d/backends/*/*.core
> > run-tests.sh looks only for "/core*" when looking for cores.
> >
> > So, at the end of test run when regression.sh looks for core everywhere,
> > it finds one and errors out.
> So does that mean we never analyzed any core reported by NetBSD
> regression failure? That's strange.
>

I wonder when these changes were done.

Manu,

Where do I find config in NetBSD which decides which location to dump core
in?
Any particular reason you added /d/backends/*/*.core to list of path to
search for core?

>
> > Should think of a solution which is generic. Will update.
> >
>
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel