[jira] [Created] (MESOS-6346) mesos trace should be available to upstream

2016-10-08 Thread Jacky Wu (JIRA) 
Jacky Wu created MESOS-6346:
---

 Summary: mesos trace should be available to upstream
 Key: MESOS-6346
 URL: https://issues.apache.org/jira/browse/MESOS-6346
 Project: Mesos
  Issue Type: Wish
  Components: general
Affects Versions: 1.0.1, 0.28.2
Reporter: Jacky Wu
Priority: Minor


As https://github.com/mesosphere/mesos-tracing introduced a way to easily 
debugging mesos http request, I can know more deep in the schedule.now, it 
seems still not available in upstream. 

Why not release this feat? I'm really interested in that.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-6345) ExamplesTest.PersistentVolumeFramework failing due to double free corruption on Ubuntu 14.04

2016-10-08 Thread Anand Mazumdar (JIRA) 

[ 
https://issues.apache.org/jira/browse/MESOS-6345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15559048#comment-15559048
 ] 

Anand Mazumdar commented on MESOS-6345:
---

[~avin...@mesosphere.io] Would it be possible to also paste the full log for 
the test run?

> ExamplesTest.PersistentVolumeFramework failing due to double free corruption 
> on Ubuntu 14.04
> 
>
> Key: MESOS-6345
> URL: https://issues.apache.org/jira/browse/MESOS-6345
> Project: Mesos
>  Issue Type: Bug
>  Components: framework
>Reporter: Avinash Sridharan
>  Labels: mesosphere
>
> PersistentVolumeFramework tests if failing on Ubuntu 14
> {code}
> [Step 10/10] *** Error in 
> `/mnt/teamcity/work/4240ba9ddd0997c3/build/src/.libs/lt-persistent-volume-framework':
>  double free or corruption (fasttop): 0x7f1ae0006a20 ***
> [04:56:48]W:   [Step 10/10] *** Aborted at 1475902608 (unix time) try "date 
> -d @1475902608" if you are using GNU date ***
> [04:56:48]W:   [Step 10/10] I1008 04:56:48.592744 25425 state.cpp:57] 
> Recovering state from '/mnt/teamcity/temp/buildTmp/mesos-8KiPML/2/meta'
> [04:56:48]W:   [Step 10/10] I1008 04:56:48.592808 25423 state.cpp:57] 
> Recovering state from '/mnt/teamcity/temp/buildTmp/mesos-8KiPML/1/meta'
> [04:56:48]W:   [Step 10/10] I1008 04:56:48.592952 25425 
> status_update_manager.cpp:203] Recovering status update manager
> [04:56:48]W:   [Step 10/10] I1008 04:56:48.592957 25423 
> status_update_manager.cpp:203] Recovering status update manager
> [04:56:48]W:   [Step 10/10] I1008 04:56:48.593010 25424 
> containerizer.cpp:557] Recovering containerizer
> [04:56:48]W:   [Step 10/10] I1008 04:56:48.593143 25396 sched.cpp:226] 
> Version: 1.1.0
> [04:56:48]W:   [Step 10/10] I1008 04:56:48.593158 25425 master.cpp:2013] 
> Elected as the leading master!
> [04:56:48]W:   [Step 10/10] I1008 04:56:48.593173 25425 master.cpp:1560] 
> Recovering from registrar
> [04:56:48]W:   [Step 10/10] I1008 04:56:48.593211 25424 registrar.cpp:329] 
> Recovering registrar
> [04:56:48]W:   [Step 10/10] I1008 04:56:48.593250 25425 sched.cpp:330] New 
> master detected at master@172.30.2.21:45167
> [04:56:48]W:   [Step 10/10] I1008 04:56:48.593282 25425 sched.cpp:341] No 
> credentials provided. Attempting to register without authentication
> [04:56:48]W:   [Step 10/10] I1008 04:56:48.593293 25425 sched.cpp:820] 
> Sending SUBSCRIBE call to master@172.30.2.21:45167
> [04:56:48]W:   [Step 10/10] PC: @ 0x7f1b0bbaccc9 (unknown)
> [04:56:48]W:   [Step 10/10] I1008 04:56:48.593339 25425 sched.cpp:853] Will 
> retry registration in 32.354951ms if necessary
> [04:56:48]W:   [Step 10/10] I1008 04:56:48.593364 25421 master.cpp:1387] 
> Dropping 'mesos.scheduler.Call' message since not recovered yet
> [04:56:48]W:   [Step 10/10] I1008 04:56:48.593413 25428 provisioner.cpp:253] 
> Provisioner recovery complete
> [04:56:48]W:   [Step 10/10] *** SIGABRT (@0x6334) received by PID 25396 (TID 
> 0x7f1b02ed6700) from PID 25396; stack trace: ***
> [04:56:48]W:   [Step 10/10] I1008 04:56:48.593520 25421 
> containerizer.cpp:557] Recovering containerizer
> [04:56:48]W:   [Step 10/10] I1008 04:56:48.593529 25425 slave.cpp:5276] 
> Finished recovery
> [04:56:48]W:   [Step 10/10] I1008 04:56:48.593627 25422 leveldb.cpp:304] 
> Persisting metadata (8 bytes) to leveldb took 4.546422ms
> [04:56:48]W:   [Step 10/10] I1008 04:56:48.593695 25428 provisioner.cpp:253] 
> Provisioner recovery complete
> [04:56:48]W:   [Step 10/10] I1008 04:56:48.593701 25422 replica.cpp:320] 
> Persisted replica status to VOTING
> [04:56:48]W:   [Step 10/10] I1008 04:56:48.593760 25424 slave.cpp:5276] 
> Finished recovery
> [04:56:48]W:   [Step 10/10] I1008 04:56:48.593864 25427 recover.cpp:582] 
> Successfully joined the Paxos group
> [04:56:48]W:   [Step 10/10] I1008 04:56:48.593896 25425 slave.cpp:5448] 
> Querying resource estimator for oversubscribable resources
> [04:56:48]W:   [Step 10/10] I1008 04:56:48.593922 25427 recover.cpp:466] 
> Recover process terminated
> [04:56:48]W:   [Step 10/10] I1008 04:56:48.593976 25427 slave.cpp:5462] 
> Received oversubscribable resources {} from the resource estimator
> [04:56:48]W:   [Step 10/10] I1008 04:56:48.594002 25424 slave.cpp:5448] 
> Querying resource estimator for oversubscribable resources
> [04:56:48]W:   [Step 10/10] I1008 04:56:48.594017 25422 log.cpp:553] 
> Attempting to start the writer
> [04:56:48]W:   [Step 10/10] I1008 04:56:48.594030 25428 
> status_update_manager.cpp:177] Pausing sending status updates
> [04:56:48]W:   [Step 10/10] I1008 04:56:48.594032 25427 slave.cpp:915] New 
> master detected at master@172.30.2.21:45167
> [04:56:48]W:   [Step 10/10] I1008 04:56:48.594055 25423 slave.cpp:915] New 
> master detected at master@172.30.2.21:45167
> [04:56:48]W:

[jira] [Commented] (MESOS-6063) Track recovered and prepared subsystems for a container

2016-10-08 Thread Jie Yu (JIRA) 

[ 
https://issues.apache.org/jira/browse/MESOS-6063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15558741#comment-15558741
 ] 

Jie Yu commented on MESOS-6063:
---

commit e7703d1c88936d2b684b43c4a902333b33c808ff
Author: Jie Yu 
Date:   Sat Oct 8 14:20:47 2016 -0700

Made some adjustments to the cgroups isolator tests.

This patch makes sure that the cgroups will be cleaned up for each
test by using the ContainerizerTest fixture.

commit 9118eded36b3e61a0727fa328540e7da1b9402f0
Author: haosdent huang 
Date:   Sat Oct 8 10:45:18 2016 -0700

Added test case `CgroupsIsolatorTest.ROOT_CGROUPS_MemoryBackward`.

Review: https://reviews.apache.org/r/52244/

commit 96c866d36e49dd76a5819154a023c5a23d8ae074
Author: haosdent huang 
Date:   Sat Oct 8 10:45:07 2016 -0700

Added test case `CgroupsIsolatorTest.ROOT_CGROUPS_MemoryForward`.

Review: https://reviews.apache.org/r/52243/

> Track recovered and prepared subsystems for a container
> ---
>
> Key: MESOS-6063
> URL: https://issues.apache.org/jira/browse/MESOS-6063
> Project: Mesos
>  Issue Type: Improvement
>  Components: cgroups
>Reporter: haosdent
>Assignee: haosdent
>  Labels: cgroups
> Fix For: 1.1.0
>
>
> Currently, when we restart Mesos Agent with different cgroups subsystems, the 
> exist containers would recover failed on newly added subsystems. In this 
> case, we ignore them and continue to perform {{usage}}, {{status}} and 
> {{cleanup}} on them.  It would be better that we track recovered and prepared 
> subsystems for a container. Then ignore perform {{update}}, {{wait}}, 
> {{usage}}, {{status}} on them.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-5879) cgroups/net_cls isolator causing agent recovery issues

2016-10-08 Thread Avinash Sridharan (JIRA) 

[ 
https://issues.apache.org/jira/browse/MESOS-5879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15558384#comment-15558384
 ] 

Avinash Sridharan commented on MESOS-5879:
--

Implements a non-recursive version of cgroups::get

> cgroups/net_cls isolator causing agent recovery issues
> --
>
> Key: MESOS-5879
> URL: https://issues.apache.org/jira/browse/MESOS-5879
> Project: Mesos
>  Issue Type: Bug
>  Components: cgroups, isolation, slave
>Reporter: Silas Snider
>Assignee: Avinash Sridharan
>  Labels: mesosphere
>
> We run with 'cgroups/net_cls' in our isolator list, and when we restart any 
> agent process in a cluster running an experimental custom isolator as well, 
> the agents are unable to recover from checkpoint, because net_cls reports 
> that unknown orphan containers have duplicate net_cls handles.
> While this is a problem that needs to be solved (probably by fixing our 
> custom isolator), it's also a problem that the net_cls isolator fails 
> recovery just for duplicate handles in cgroups that it is literally about to 
> unconditionally destroy during recovery. Can this be fixed?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-5879) cgroups/net_cls isolator causing agent recovery issues

2016-10-08 Thread Avinash Sridharan (JIRA) 

[ 
https://issues.apache.org/jira/browse/MESOS-5879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15558382#comment-15558382
 ] 

Avinash Sridharan commented on MESOS-5879:
--

Great !!

I would still keep this open. Will just mark this as "is blocked by MESOS-6035" 
and close this once MESOS-6035 is fixed. This is not exactly a duplicate, but a 
side affect of the recursive cgroups::get.

> cgroups/net_cls isolator causing agent recovery issues
> --
>
> Key: MESOS-5879
> URL: https://issues.apache.org/jira/browse/MESOS-5879
> Project: Mesos
>  Issue Type: Bug
>  Components: cgroups, isolation, slave
>Reporter: Silas Snider
>Assignee: Avinash Sridharan
>  Labels: mesosphere
>
> We run with 'cgroups/net_cls' in our isolator list, and when we restart any 
> agent process in a cluster running an experimental custom isolator as well, 
> the agents are unable to recover from checkpoint, because net_cls reports 
> that unknown orphan containers have duplicate net_cls handles.
> While this is a problem that needs to be solved (probably by fixing our 
> custom isolator), it's also a problem that the net_cls isolator fails 
> recovery just for duplicate handles in cgroups that it is literally about to 
> unconditionally destroy during recovery. Can this be fixed?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-5879) cgroups/net_cls isolator causing agent recovery issues

2016-10-08 Thread haosdent (JIRA) 

[ 
https://issues.apache.org/jira/browse/MESOS-5879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15558374#comment-15558374
 ] 

haosdent commented on MESOS-5879:
-

But let's keep this open, because I am no sure if non-recursive is the prefer 
default behaviour for now. 

> cgroups/net_cls isolator causing agent recovery issues
> --
>
> Key: MESOS-5879
> URL: https://issues.apache.org/jira/browse/MESOS-5879
> Project: Mesos
>  Issue Type: Bug
>  Components: cgroups, isolation, slave
>Reporter: Silas Snider
>Assignee: Avinash Sridharan
>  Labels: mesosphere
>
> We run with 'cgroups/net_cls' in our isolator list, and when we restart any 
> agent process in a cluster running an experimental custom isolator as well, 
> the agents are unable to recover from checkpoint, because net_cls reports 
> that unknown orphan containers have duplicate net_cls handles.
> While this is a problem that needs to be solved (probably by fixing our 
> custom isolator), it's also a problem that the net_cls isolator fails 
> recovery just for duplicate handles in cgroups that it is literally about to 
> unconditionally destroy during recovery. Can this be fixed?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-5879) cgroups/net_cls isolator causing agent recovery issues

2016-10-08 Thread haosdent (JIRA) 

[ 
https://issues.apache.org/jira/browse/MESOS-5879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15558371#comment-15558371
 ] 

haosdent commented on MESOS-5879:
-

no need, the default one is non-recursive.

> cgroups/net_cls isolator causing agent recovery issues
> --
>
> Key: MESOS-5879
> URL: https://issues.apache.org/jira/browse/MESOS-5879
> Project: Mesos
>  Issue Type: Bug
>  Components: cgroups, isolation, slave
>Reporter: Silas Snider
>Assignee: Avinash Sridharan
>  Labels: mesosphere
>
> We run with 'cgroups/net_cls' in our isolator list, and when we restart any 
> agent process in a cluster running an experimental custom isolator as well, 
> the agents are unable to recover from checkpoint, because net_cls reports 
> that unknown orphan containers have duplicate net_cls handles.
> While this is a problem that needs to be solved (probably by fixing our 
> custom isolator), it's also a problem that the net_cls isolator fails 
> recovery just for duplicate handles in cgroups that it is literally about to 
> unconditionally destroy during recovery. Can this be fixed?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-5879) cgroups/net_cls isolator causing agent recovery issues

2016-10-08 Thread Avinash Sridharan (JIRA) 

[ 
https://issues.apache.org/jira/browse/MESOS-5879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15558364#comment-15558364
 ] 

Avinash Sridharan commented on MESOS-5879:
--

I think we should keep this open, since even after we fix MESOS-6035 the 
Net_Cls subsystem will need to be changed to use the non-recursive cgroups::get 
to fix this right?

> cgroups/net_cls isolator causing agent recovery issues
> --
>
> Key: MESOS-5879
> URL: https://issues.apache.org/jira/browse/MESOS-5879
> Project: Mesos
>  Issue Type: Bug
>  Components: cgroups, isolation, slave
>Reporter: Silas Snider
>Assignee: Avinash Sridharan
>  Labels: mesosphere
>
> We run with 'cgroups/net_cls' in our isolator list, and when we restart any 
> agent process in a cluster running an experimental custom isolator as well, 
> the agents are unable to recover from checkpoint, because net_cls reports 
> that unknown orphan containers have duplicate net_cls handles.
> While this is a problem that needs to be solved (probably by fixing our 
> custom isolator), it's also a problem that the net_cls isolator fails 
> recovery just for duplicate handles in cgroups that it is literally about to 
> unconditionally destroy during recovery. Can this be fixed?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MESOS-6345) ExamplesTest.PersistentVolumeFramework failing due to double free corruption on Ubuntu 14.04

2016-10-08 Thread haosdent (JIRA) 

 [ 
https://issues.apache.org/jira/browse/MESOS-6345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

haosdent updated MESOS-6345:

Description: 
PersistentVolumeFramework tests if failing on Ubuntu 14
{code}
[Step 10/10] *** Error in 
`/mnt/teamcity/work/4240ba9ddd0997c3/build/src/.libs/lt-persistent-volume-framework':
 double free or corruption (fasttop): 0x7f1ae0006a20 ***
[04:56:48]W: [Step 10/10] *** Aborted at 1475902608 (unix time) try "date 
-d @1475902608" if you are using GNU date ***
[04:56:48]W: [Step 10/10] I1008 04:56:48.592744 25425 state.cpp:57] 
Recovering state from '/mnt/teamcity/temp/buildTmp/mesos-8KiPML/2/meta'
[04:56:48]W: [Step 10/10] I1008 04:56:48.592808 25423 state.cpp:57] 
Recovering state from '/mnt/teamcity/temp/buildTmp/mesos-8KiPML/1/meta'
[04:56:48]W: [Step 10/10] I1008 04:56:48.592952 25425 
status_update_manager.cpp:203] Recovering status update manager
[04:56:48]W: [Step 10/10] I1008 04:56:48.592957 25423 
status_update_manager.cpp:203] Recovering status update manager
[04:56:48]W: [Step 10/10] I1008 04:56:48.593010 25424 
containerizer.cpp:557] Recovering containerizer
[04:56:48]W: [Step 10/10] I1008 04:56:48.593143 25396 sched.cpp:226] 
Version: 1.1.0
[04:56:48]W: [Step 10/10] I1008 04:56:48.593158 25425 master.cpp:2013] 
Elected as the leading master!
[04:56:48]W: [Step 10/10] I1008 04:56:48.593173 25425 master.cpp:1560] 
Recovering from registrar
[04:56:48]W: [Step 10/10] I1008 04:56:48.593211 25424 registrar.cpp:329] 
Recovering registrar
[04:56:48]W: [Step 10/10] I1008 04:56:48.593250 25425 sched.cpp:330] New 
master detected at master@172.30.2.21:45167
[04:56:48]W: [Step 10/10] I1008 04:56:48.593282 25425 sched.cpp:341] No 
credentials provided. Attempting to register without authentication
[04:56:48]W: [Step 10/10] I1008 04:56:48.593293 25425 sched.cpp:820] 
Sending SUBSCRIBE call to master@172.30.2.21:45167
[04:56:48]W: [Step 10/10] PC: @ 0x7f1b0bbaccc9 (unknown)
[04:56:48]W: [Step 10/10] I1008 04:56:48.593339 25425 sched.cpp:853] Will 
retry registration in 32.354951ms if necessary
[04:56:48]W: [Step 10/10] I1008 04:56:48.593364 25421 master.cpp:1387] 
Dropping 'mesos.scheduler.Call' message since not recovered yet
[04:56:48]W: [Step 10/10] I1008 04:56:48.593413 25428 provisioner.cpp:253] 
Provisioner recovery complete
[04:56:48]W: [Step 10/10] *** SIGABRT (@0x6334) received by PID 25396 (TID 
0x7f1b02ed6700) from PID 25396; stack trace: ***
[04:56:48]W: [Step 10/10] I1008 04:56:48.593520 25421 
containerizer.cpp:557] Recovering containerizer
[04:56:48]W: [Step 10/10] I1008 04:56:48.593529 25425 slave.cpp:5276] 
Finished recovery
[04:56:48]W: [Step 10/10] I1008 04:56:48.593627 25422 leveldb.cpp:304] 
Persisting metadata (8 bytes) to leveldb took 4.546422ms
[04:56:48]W: [Step 10/10] I1008 04:56:48.593695 25428 provisioner.cpp:253] 
Provisioner recovery complete
[04:56:48]W: [Step 10/10] I1008 04:56:48.593701 25422 replica.cpp:320] 
Persisted replica status to VOTING
[04:56:48]W: [Step 10/10] I1008 04:56:48.593760 25424 slave.cpp:5276] 
Finished recovery
[04:56:48]W: [Step 10/10] I1008 04:56:48.593864 25427 recover.cpp:582] 
Successfully joined the Paxos group
[04:56:48]W: [Step 10/10] I1008 04:56:48.593896 25425 slave.cpp:5448] 
Querying resource estimator for oversubscribable resources
[04:56:48]W: [Step 10/10] I1008 04:56:48.593922 25427 recover.cpp:466] 
Recover process terminated
[04:56:48]W: [Step 10/10] I1008 04:56:48.593976 25427 slave.cpp:5462] 
Received oversubscribable resources {} from the resource estimator
[04:56:48]W: [Step 10/10] I1008 04:56:48.594002 25424 slave.cpp:5448] 
Querying resource estimator for oversubscribable resources
[04:56:48]W: [Step 10/10] I1008 04:56:48.594017 25422 log.cpp:553] 
Attempting to start the writer
[04:56:48]W: [Step 10/10] I1008 04:56:48.594030 25428 
status_update_manager.cpp:177] Pausing sending status updates
[04:56:48]W: [Step 10/10] I1008 04:56:48.594032 25427 slave.cpp:915] New 
master detected at master@172.30.2.21:45167
[04:56:48]W: [Step 10/10] I1008 04:56:48.594055 25423 slave.cpp:915] New 
master detected at master@172.30.2.21:45167
[04:56:48]W: [Step 10/10] I1008 04:56:48.594048 25428 
status_update_manager.cpp:177] Pausing sending status updates
[04:56:48]W: [Step 10/10] I1008 04:56:48.594061 25427 slave.cpp:936] No 
credentials provided. Attempting to register without authentication
[04:56:48]W: [Step 10/10] I1008 04:56:48.594106 25427 slave.cpp:947] 
Detecting new master
[04:56:48]W: [Step 10/10] I1008 04:56:48.594071 25423 slave.cpp:936] No 
credentials provided. Attempting to register without authentication
[04:56:48]W: [Step 10/10] @ 0x7f1b0bf4b340 (unknown)
[04:56:48]W: [Step 10/10] I1008 04:56:48.594125 25423 slave.cpp:947] 
Detecting new master
[04:56:48]W: [Step

[jira] [Assigned] (MESOS-5925) Building Mesos in Docker 1.12 on OS X fails - tar issue in Makefile

2016-10-08 Thread haosdent (JIRA) 

 [ 
https://issues.apache.org/jira/browse/MESOS-5925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

haosdent reassigned MESOS-5925:
---

Assignee: haosdent

> Building Mesos in Docker 1.12 on OS X fails - tar issue in Makefile
> ---
>
> Key: MESOS-5925
> URL: https://issues.apache.org/jira/browse/MESOS-5925
> Project: Mesos
>  Issue Type: Bug
>  Components: build
>Reporter: Radoslaw Gruchalski
>Assignee: haosdent
>
> I am building Mesos from sources using Docker Beta OS X. I have hit an issue 
> today while trying to build the following versions:
> - master
> - 1.0.0
> - 0.28.2
> but this problem will most likely apply to any version where this line: 
> https://github.com/apache/mesos/blame/master/3rdparty/Makefile.am#L132 is in 
> effect.
> The way I'm building:
> I have the Mesos sources locally on the disk, I copy the sources to a *build 
> temp source* directory, start the container and attach the *build temp 
> source* as a volume to the docker container. Wnen executing the build with 
> mesos-deb-packaging, I hit the following problem:
> {noformat}
> Making all in libprocess
> make[3]: Entering directory `/mesos-src/build/3rdparty/libprocess'
> Making all in 3rdparty
> make[4]: Entering directory `/mesos-src/build/3rdparty/libprocess/3rdparty'
> gzip -d -c 
> ../../../../3rdparty/libprocess/3rdparty/ry-http-parser-1c3624a.tar.gz | tar 
> xf -
> test ! -e 
> ../../../../3rdparty/libprocess/3rdparty/ry-http-parser-1c3624a.patch || 
> patch -d ry-http-parser-1c3624a -p1 
> <../../../../3rdparty/libprocess/3rdparty/ry-http-parser-1c3624a.patch
> touch ry-http-parser-1c3624a-stamp
> gzip -d -c ../../../../3rdparty/libprocess/3rdparty/gmock-1.7.0.tar.gz | tar 
> xf -
> tar: gmock-1.7.0/CHANGES: Cannot change ownership to uid 501, gid 10: 
> Permission denied
> tar: gmock-1.7.0/CMakeLists.txt: Cannot change ownership to uid 501, gid 10: 
> Permission denied
> tar: gmock-1.7.0/configure.ac: Cannot change ownership to uid 501, gid 10: 
> Permission denied
> tar: gmock-1.7.0/CONTRIBUTORS: Cannot change ownership to uid 501, gid 10: 
> Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-actions.h: Cannot change ownership to 
> uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-cardinalities.h: Cannot change ownership 
> to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-actions.h: Cannot change 
> ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-actions.h.pump: Cannot change 
> ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-function-mockers.h: Cannot 
> change ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-function-mockers.h.pump: 
> Cannot change ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-matchers.h: Cannot change 
> ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-matchers.h.pump: Cannot change 
> ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-nice-strict.h: Cannot change 
> ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-nice-strict.h.pump: Cannot 
> change ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-matchers.h: Cannot change ownership to 
> uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-more-actions.h: Cannot change ownership 
> to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-more-matchers.h: Cannot change ownership 
> to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-spec-builders.h: Cannot change ownership 
> to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock.h: Cannot change ownership to uid 501, 
> gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/internal/gmock-generated-internal-utils.h: 
> Cannot change ownership to uid 501, gid 10: Permission denied
> tar: 
> gmock-1.7.0/include/gmock/internal/gmock-generated-internal-utils.h.pump: 
> Cannot change ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/internal/gmock-internal-utils.h: Cannot change 
> ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/internal/gmock-port.h: Cannot change ownership 
> to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/LICENSE: Cannot change ownership to uid 501, gid 10: 
> Permission denied
> tar: gmock-1.7.0/make/Makefile: Cannot change ownership to uid 501, gid 10: 
> Permission denied
> tar: gmock-1.7.0/Makefile.am: Cannot change ownership to uid 501, gid 10: 
> Permission denied
>

[jira] [Updated] (MESOS-5925) Building Mesos in Docker 1.12 on OS X fails - tar issue in Makefile

2016-10-08 Thread haosdent (JIRA) 

 [ 
https://issues.apache.org/jira/browse/MESOS-5925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

haosdent updated MESOS-5925:

Summary: Building Mesos in Docker 1.12 on OS X fails - tar issue in 
Makefile  (was: Building Mesos in Docker Beta on OS X fails - tar issue in 
Makefile)

> Building Mesos in Docker 1.12 on OS X fails - tar issue in Makefile
> ---
>
> Key: MESOS-5925
> URL: https://issues.apache.org/jira/browse/MESOS-5925
> Project: Mesos
>  Issue Type: Bug
>  Components: build
>Reporter: Radoslaw Gruchalski
>
> I am building Mesos from sources using Docker Beta OS X. I have hit an issue 
> today while trying to build the following versions:
> - master
> - 1.0.0
> - 0.28.2
> but this problem will most likely apply to any version where this line: 
> https://github.com/apache/mesos/blame/master/3rdparty/Makefile.am#L132 is in 
> effect.
> The way I'm building:
> I have the Mesos sources locally on the disk, I copy the sources to a *build 
> temp source* directory, start the container and attach the *build temp 
> source* as a volume to the docker container. Wnen executing the build with 
> mesos-deb-packaging, I hit the following problem:
> {noformat}
> Making all in libprocess
> make[3]: Entering directory `/mesos-src/build/3rdparty/libprocess'
> Making all in 3rdparty
> make[4]: Entering directory `/mesos-src/build/3rdparty/libprocess/3rdparty'
> gzip -d -c 
> ../../../../3rdparty/libprocess/3rdparty/ry-http-parser-1c3624a.tar.gz | tar 
> xf -
> test ! -e 
> ../../../../3rdparty/libprocess/3rdparty/ry-http-parser-1c3624a.patch || 
> patch -d ry-http-parser-1c3624a -p1 
> <../../../../3rdparty/libprocess/3rdparty/ry-http-parser-1c3624a.patch
> touch ry-http-parser-1c3624a-stamp
> gzip -d -c ../../../../3rdparty/libprocess/3rdparty/gmock-1.7.0.tar.gz | tar 
> xf -
> tar: gmock-1.7.0/CHANGES: Cannot change ownership to uid 501, gid 10: 
> Permission denied
> tar: gmock-1.7.0/CMakeLists.txt: Cannot change ownership to uid 501, gid 10: 
> Permission denied
> tar: gmock-1.7.0/configure.ac: Cannot change ownership to uid 501, gid 10: 
> Permission denied
> tar: gmock-1.7.0/CONTRIBUTORS: Cannot change ownership to uid 501, gid 10: 
> Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-actions.h: Cannot change ownership to 
> uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-cardinalities.h: Cannot change ownership 
> to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-actions.h: Cannot change 
> ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-actions.h.pump: Cannot change 
> ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-function-mockers.h: Cannot 
> change ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-function-mockers.h.pump: 
> Cannot change ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-matchers.h: Cannot change 
> ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-matchers.h.pump: Cannot change 
> ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-nice-strict.h: Cannot change 
> ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-generated-nice-strict.h.pump: Cannot 
> change ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-matchers.h: Cannot change ownership to 
> uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-more-actions.h: Cannot change ownership 
> to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-more-matchers.h: Cannot change ownership 
> to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock-spec-builders.h: Cannot change ownership 
> to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/gmock.h: Cannot change ownership to uid 501, 
> gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/internal/gmock-generated-internal-utils.h: 
> Cannot change ownership to uid 501, gid 10: Permission denied
> tar: 
> gmock-1.7.0/include/gmock/internal/gmock-generated-internal-utils.h.pump: 
> Cannot change ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/internal/gmock-internal-utils.h: Cannot change 
> ownership to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/include/gmock/internal/gmock-port.h: Cannot change ownership 
> to uid 501, gid 10: Permission denied
> tar: gmock-1.7.0/LICENSE: Cannot change ownership to uid 501, gid 10: 
> Permission denied
> tar: gmock-1.7.0/make/Makefile: Cannot change ownership to uid 501, gid 10: 
> Permission denied
>

[jira] [Created] (MESOS-6345) ExamplesTest.PersistentVolumeFramework failing due to double free corruption on Ubuntu 14.04

2016-10-08 Thread Avinash Sridharan (JIRA) 
Avinash Sridharan created MESOS-6345:


 Summary: ExamplesTest.PersistentVolumeFramework failing due to 
double free corruption on Ubuntu 14.04
 Key: MESOS-6345
 URL: https://issues.apache.org/jira/browse/MESOS-6345
 Project: Mesos
  Issue Type: Bug
  Components: framework
Reporter: Avinash Sridharan



PersistentVolumeFramework tests if failing on Ubuntu 14
```
[Step 10/10] *** Error in 
`/mnt/teamcity/work/4240ba9ddd0997c3/build/src/.libs/lt-persistent-volume-framework':
 double free or corruption (fasttop): 0x7f1ae0006a20 ***
[04:56:48]W: [Step 10/10] *** Aborted at 1475902608 (unix time) try "date 
-d @1475902608" if you are using GNU date ***
[04:56:48]W: [Step 10/10] I1008 04:56:48.592744 25425 state.cpp:57] 
Recovering state from '/mnt/teamcity/temp/buildTmp/mesos-8KiPML/2/meta'
[04:56:48]W: [Step 10/10] I1008 04:56:48.592808 25423 state.cpp:57] 
Recovering state from '/mnt/teamcity/temp/buildTmp/mesos-8KiPML/1/meta'
[04:56:48]W: [Step 10/10] I1008 04:56:48.592952 25425 
status_update_manager.cpp:203] Recovering status update manager
[04:56:48]W: [Step 10/10] I1008 04:56:48.592957 25423 
status_update_manager.cpp:203] Recovering status update manager
[04:56:48]W: [Step 10/10] I1008 04:56:48.593010 25424 
containerizer.cpp:557] Recovering containerizer
[04:56:48]W: [Step 10/10] I1008 04:56:48.593143 25396 sched.cpp:226] 
Version: 1.1.0
[04:56:48]W: [Step 10/10] I1008 04:56:48.593158 25425 master.cpp:2013] 
Elected as the leading master!
[04:56:48]W: [Step 10/10] I1008 04:56:48.593173 25425 master.cpp:1560] 
Recovering from registrar
[04:56:48]W: [Step 10/10] I1008 04:56:48.593211 25424 registrar.cpp:329] 
Recovering registrar
[04:56:48]W: [Step 10/10] I1008 04:56:48.593250 25425 sched.cpp:330] New 
master detected at master@172.30.2.21:45167
[04:56:48]W: [Step 10/10] I1008 04:56:48.593282 25425 sched.cpp:341] No 
credentials provided. Attempting to register without authentication
[04:56:48]W: [Step 10/10] I1008 04:56:48.593293 25425 sched.cpp:820] 
Sending SUBSCRIBE call to master@172.30.2.21:45167
[04:56:48]W: [Step 10/10] PC: @ 0x7f1b0bbaccc9 (unknown)
[04:56:48]W: [Step 10/10] I1008 04:56:48.593339 25425 sched.cpp:853] Will 
retry registration in 32.354951ms if necessary
[04:56:48]W: [Step 10/10] I1008 04:56:48.593364 25421 master.cpp:1387] 
Dropping 'mesos.scheduler.Call' message since not recovered yet
[04:56:48]W: [Step 10/10] I1008 04:56:48.593413 25428 provisioner.cpp:253] 
Provisioner recovery complete
[04:56:48]W: [Step 10/10] *** SIGABRT (@0x6334) received by PID 25396 (TID 
0x7f1b02ed6700) from PID 25396; stack trace: ***
[04:56:48]W: [Step 10/10] I1008 04:56:48.593520 25421 
containerizer.cpp:557] Recovering containerizer
[04:56:48]W: [Step 10/10] I1008 04:56:48.593529 25425 slave.cpp:5276] 
Finished recovery
[04:56:48]W: [Step 10/10] I1008 04:56:48.593627 25422 leveldb.cpp:304] 
Persisting metadata (8 bytes) to leveldb took 4.546422ms
[04:56:48]W: [Step 10/10] I1008 04:56:48.593695 25428 provisioner.cpp:253] 
Provisioner recovery complete
[04:56:48]W: [Step 10/10] I1008 04:56:48.593701 25422 replica.cpp:320] 
Persisted replica status to VOTING
[04:56:48]W: [Step 10/10] I1008 04:56:48.593760 25424 slave.cpp:5276] 
Finished recovery
[04:56:48]W: [Step 10/10] I1008 04:56:48.593864 25427 recover.cpp:582] 
Successfully joined the Paxos group
[04:56:48]W: [Step 10/10] I1008 04:56:48.593896 25425 slave.cpp:5448] 
Querying resource estimator for oversubscribable resources
[04:56:48]W: [Step 10/10] I1008 04:56:48.593922 25427 recover.cpp:466] 
Recover process terminated
[04:56:48]W: [Step 10/10] I1008 04:56:48.593976 25427 slave.cpp:5462] 
Received oversubscribable resources {} from the resource estimator
[04:56:48]W: [Step 10/10] I1008 04:56:48.594002 25424 slave.cpp:5448] 
Querying resource estimator for oversubscribable resources
[04:56:48]W: [Step 10/10] I1008 04:56:48.594017 25422 log.cpp:553] 
Attempting to start the writer
[04:56:48]W: [Step 10/10] I1008 04:56:48.594030 25428 
status_update_manager.cpp:177] Pausing sending status updates
[04:56:48]W: [Step 10/10] I1008 04:56:48.594032 25427 slave.cpp:915] New 
master detected at master@172.30.2.21:45167
[04:56:48]W: [Step 10/10] I1008 04:56:48.594055 25423 slave.cpp:915] New 
master detected at master@172.30.2.21:45167
[04:56:48]W: [Step 10/10] I1008 04:56:48.594048 25428 
status_update_manager.cpp:177] Pausing sending status updates
[04:56:48]W: [Step 10/10] I1008 04:56:48.594061 25427 slave.cpp:936] No 
credentials provided. Attempting to register without authentication
[04:56:48]W: [Step 10/10] I1008 04:56:48.594106 25427 slave.cpp:947] 
Detecting new master
[04:56:48]W: [Step 10/10] I1008 04:56:48.594071 25423 slave.cpp:936] No 
credentials provided.

[jira] [Updated] (MESOS-6035) Add non-recursive version of cgroups::get

2016-10-08 Thread haosdent (JIRA) 

 [ 
https://issues.apache.org/jira/browse/MESOS-6035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

haosdent updated MESOS-6035:

Target Version/s: 1.1.0

> Add non-recursive version of cgroups::get
> -
>
> Key: MESOS-6035
> URL: https://issues.apache.org/jira/browse/MESOS-6035
> Project: Mesos
>  Issue Type: Improvement
>Reporter: haosdent
>Assignee: haosdent
>Priority: Minor
>
> In some cases, we only need to get the top level cgroups instead of to get 
> all cgroups recursively. Add a non-recursive version could help to avoid 
> unnecessary paths.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MESOS-5879) cgroups/net_cls isolator causing agent recovery issues

2016-10-08 Thread haosdent (JIRA) 

[ 
https://issues.apache.org/jira/browse/MESOS-5879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15557540#comment-15557540
 ] 

haosdent commented on MESOS-5879:
-

yep, how about mark this duplicated?

> cgroups/net_cls isolator causing agent recovery issues
> --
>
> Key: MESOS-5879
> URL: https://issues.apache.org/jira/browse/MESOS-5879
> Project: Mesos
>  Issue Type: Bug
>  Components: cgroups, isolation, slave
>Reporter: Silas Snider
>Assignee: Avinash Sridharan
>  Labels: mesosphere
>
> We run with 'cgroups/net_cls' in our isolator list, and when we restart any 
> agent process in a cluster running an experimental custom isolator as well, 
> the agents are unable to recover from checkpoint, because net_cls reports 
> that unknown orphan containers have duplicate net_cls handles.
> While this is a problem that needs to be solved (probably by fixing our 
> custom isolator), it's also a problem that the net_cls isolator fails 
> recovery just for duplicate handles in cgroups that it is literally about to 
> unconditionally destroy during recovery. Can this be fixed?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)