[jira] [Commented] (MESOS-2050) InMemoryAuxProp plugin used by Authenticators results in SEGFAULT
[
https://issues.apache.org/jira/browse/MESOS-2050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14384861#comment-14384861
]
Adam B commented on MESOS-2050:
---
Still need to land the last patch (r/27760), but its prerequisites are now
committed.
commit 4809d161ee6ba51983027f358691af1c779fb915
Author: Till Toenshoff toensh...@me.com
Date: Fri Mar 27 15:25:04 2015 -0700
Split cram_md5 authenticator into declaration and implementation without
functional changes.
Review: https://reviews.apache.org/r/31961
commit 17a06589e6e64d0fee38b7e45fa338af7547a8e5
Author: Till Toenshoff toensh...@me.com
Date: Fri Mar 27 15:24:50 2015 -0700
Added concurrency protection within the SASL auxprop plugin code.
Review: https://reviews.apache.org/r/31960
commit 43abc2160f03a5b3fcc599a38b48a84f5c2b3f75
Author: Till Toenshoff toensh...@me.com
Date: Fri Mar 27 15:24:02 2015 -0700
Simplified master authentication.
Removes the wrapping by a PromiseNothing of the Authenticator
returned future from the master authentication. This should not
have any functional consequences.
Review: https://reviews.apache.org/r/31957
InMemoryAuxProp plugin used by Authenticators results in SEGFAULT
-
Key: MESOS-2050
URL: https://issues.apache.org/jira/browse/MESOS-2050
Project: Mesos
Issue Type: Bug
Affects Versions: 0.21.0
Reporter: Vinod Kone
Assignee: Adam B
Observed this on ASF CI:
Basically, as part of the recent Auth refactor for modules, the loading of
secrets is being done once per Authenticator Process instead of once in the
Master. Since, InMemoryAuxProp plugin manipulates static variables (e.g,
'properties') it results in SEGFAULT when one Authenticator (e.g., for slave)
does load() while another Authenticator (e.g., for framework) does lookup(),
as both these methods manipulate static 'properties'.
{code}
[ RUN ] MasterTest.LaunchDuplicateOfferTest
Using temporary directory '/tmp/MasterTest_LaunchDuplicateOfferTest_XEBbvp'
I1104 03:37:55.523553 28363 leveldb.cpp:176] Opened db in 2.270387ms
I1104 03:37:55.524250 28363 leveldb.cpp:183] Compacted db in 662527ns
I1104 03:37:55.524276 28363 leveldb.cpp:198] Created db iterator in 4964ns
I1104 03:37:55.524284 28363 leveldb.cpp:204] Seeked to beginning of db in
702ns
I1104 03:37:55.524291 28363 leveldb.cpp:273] Iterated through 0 keys in the
db in 450ns
I1104 03:37:55.524333 28363 replica.cpp:741] Replica recovered with log
positions 0 - 0 with 1 holes and 0 unlearned
I1104 03:37:55.524852 28384 recover.cpp:437] Starting replica recovery
I1104 03:37:55.525188 28384 recover.cpp:463] Replica is in EMPTY status
I1104 03:37:55.526577 28378 replica.cpp:638] Replica in EMPTY status received
a broadcasted recover request
I1104 03:37:55.527135 28378 master.cpp:318] Master
20141104-033755-3176252227-49988-28363 (proserpina.apache.org) started on
67.195.81.189:49988
I1104 03:37:55.527180 28378 master.cpp:364] Master only allowing
authenticated frameworks to register
I1104 03:37:55.527191 28378 master.cpp:369] Master only allowing
authenticated slaves to register
I1104 03:37:55.527217 28378 credentials.hpp:36] Loading credentials for
authentication from
'/tmp/MasterTest_LaunchDuplicateOfferTest_XEBbvp/credentials'
I1104 03:37:55.527451 28378 master.cpp:408] Authorization enabled
I1104 03:37:55.528081 28384 master.cpp:126] No whitelist given. Advertising
offers for all slaves
I1104 03:37:55.528548 28383 recover.cpp:188] Received a recover response from
a replica in EMPTY status
I1104 03:37:55.528645 28388 hierarchical_allocator_process.hpp:299]
Initializing hierarchical allocator process with master :
master@67.195.81.189:49988
I1104 03:37:55.529233 28388 master.cpp:1258] The newly elected leader is
master@67.195.81.189:49988 with id 20141104-033755-3176252227-49988-28363
I1104 03:37:55.529266 28388 master.cpp:1271] Elected as the leading master!
I1104 03:37:55.529289 28388 master.cpp:1089] Recovering from registrar
I1104 03:37:55.529311 28385 recover.cpp:554] Updating replica status to
STARTING
I1104 03:37:55.529500 28384 registrar.cpp:313] Recovering registrar
I1104 03:37:55.530037 28383 leveldb.cpp:306] Persisting metadata (8 bytes) to
leveldb took 497965ns
I1104 03:37:55.530083 28383 replica.cpp:320] Persisted replica status to
STARTING
I1104 03:37:55.530335 28387 recover.cpp:463] Replica is in STARTING status
I1104 03:37:55.531343 28381 replica.cpp:638] Replica in STARTING status
received a broadcasted recover request
I1104 03:37:55.531739 28384 recover.cpp:188] Received a recover response from
a replica in STARTING status
I1104 03:37:55.532168 28379 recover.cpp:554] Updating replica status to VOTING
I1104
[jira] [Commented] (MESOS-2050) InMemoryAuxProp plugin used by Authenticators results in SEGFAULT
[
https://issues.apache.org/jira/browse/MESOS-2050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14330072#comment-14330072
]
Adam B commented on MESOS-2050:
---
This is very close, I think. And we'd really like to see this land in 0.22 if
possible, since the Authenticator module interface we delivered in 0.21 imposes
the CRAM_MD5 authenticator's secrets-loading and auxprop-plugin loading code
onto any other authenticator implementation.
InMemoryAuxProp plugin used by Authenticators results in SEGFAULT
-
Key: MESOS-2050
URL: https://issues.apache.org/jira/browse/MESOS-2050
Project: Mesos
Issue Type: Bug
Affects Versions: 0.21.0
Reporter: Vinod Kone
Assignee: Till Toenshoff
Observed this on ASF CI:
Basically, as part of the recent Auth refactor for modules, the loading of
secrets is being done once per Authenticator Process instead of once in the
Master. Since, InMemoryAuxProp plugin manipulates static variables (e.g,
'properties') it results in SEGFAULT when one Authenticator (e.g., for slave)
does load() while another Authenticator (e.g., for framework) does lookup(),
as both these methods manipulate static 'properties'.
{code}
[ RUN ] MasterTest.LaunchDuplicateOfferTest
Using temporary directory '/tmp/MasterTest_LaunchDuplicateOfferTest_XEBbvp'
I1104 03:37:55.523553 28363 leveldb.cpp:176] Opened db in 2.270387ms
I1104 03:37:55.524250 28363 leveldb.cpp:183] Compacted db in 662527ns
I1104 03:37:55.524276 28363 leveldb.cpp:198] Created db iterator in 4964ns
I1104 03:37:55.524284 28363 leveldb.cpp:204] Seeked to beginning of db in
702ns
I1104 03:37:55.524291 28363 leveldb.cpp:273] Iterated through 0 keys in the
db in 450ns
I1104 03:37:55.524333 28363 replica.cpp:741] Replica recovered with log
positions 0 - 0 with 1 holes and 0 unlearned
I1104 03:37:55.524852 28384 recover.cpp:437] Starting replica recovery
I1104 03:37:55.525188 28384 recover.cpp:463] Replica is in EMPTY status
I1104 03:37:55.526577 28378 replica.cpp:638] Replica in EMPTY status received
a broadcasted recover request
I1104 03:37:55.527135 28378 master.cpp:318] Master
20141104-033755-3176252227-49988-28363 (proserpina.apache.org) started on
67.195.81.189:49988
I1104 03:37:55.527180 28378 master.cpp:364] Master only allowing
authenticated frameworks to register
I1104 03:37:55.527191 28378 master.cpp:369] Master only allowing
authenticated slaves to register
I1104 03:37:55.527217 28378 credentials.hpp:36] Loading credentials for
authentication from
'/tmp/MasterTest_LaunchDuplicateOfferTest_XEBbvp/credentials'
I1104 03:37:55.527451 28378 master.cpp:408] Authorization enabled
I1104 03:37:55.528081 28384 master.cpp:126] No whitelist given. Advertising
offers for all slaves
I1104 03:37:55.528548 28383 recover.cpp:188] Received a recover response from
a replica in EMPTY status
I1104 03:37:55.528645 28388 hierarchical_allocator_process.hpp:299]
Initializing hierarchical allocator process with master :
master@67.195.81.189:49988
I1104 03:37:55.529233 28388 master.cpp:1258] The newly elected leader is
master@67.195.81.189:49988 with id 20141104-033755-3176252227-49988-28363
I1104 03:37:55.529266 28388 master.cpp:1271] Elected as the leading master!
I1104 03:37:55.529289 28388 master.cpp:1089] Recovering from registrar
I1104 03:37:55.529311 28385 recover.cpp:554] Updating replica status to
STARTING
I1104 03:37:55.529500 28384 registrar.cpp:313] Recovering registrar
I1104 03:37:55.530037 28383 leveldb.cpp:306] Persisting metadata (8 bytes) to
leveldb took 497965ns
I1104 03:37:55.530083 28383 replica.cpp:320] Persisted replica status to
STARTING
I1104 03:37:55.530335 28387 recover.cpp:463] Replica is in STARTING status
I1104 03:37:55.531343 28381 replica.cpp:638] Replica in STARTING status
received a broadcasted recover request
I1104 03:37:55.531739 28384 recover.cpp:188] Received a recover response from
a replica in STARTING status
I1104 03:37:55.532168 28379 recover.cpp:554] Updating replica status to VOTING
I1104 03:37:55.532572 28381 leveldb.cpp:306] Persisting metadata (8 bytes) to
leveldb took 293974ns
I1104 03:37:55.532594 28381 replica.cpp:320] Persisted replica status to
VOTING
I1104 03:37:55.532790 28390 recover.cpp:568] Successfully joined the Paxos
group
I1104 03:37:55.533107 28390 recover.cpp:452] Recover process terminated
I1104 03:37:55.533604 28382 log.cpp:656] Attempting to start the writer
I1104 03:37:55.534840 28381 replica.cpp:474] Replica received implicit
promise request with proposal 1
I1104 03:37:55.535188 28381 leveldb.cpp:306] Persisting metadata (8 bytes) to
leveldb took 321021ns
I1104 03:37:55.535212 28381 replica.cpp:342] Persisted promised to 1
I1104 03:37:55.535893 28378
[jira] [Commented] (MESOS-2050) InMemoryAuxProp plugin used by Authenticators results in SEGFAULT
[
https://issues.apache.org/jira/browse/MESOS-2050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14323511#comment-14323511
]
Niklas Quarfot Nielsen commented on MESOS-2050:
---
Hey [~tillt] - what's the status here? Do you need any help tracking this down?
InMemoryAuxProp plugin used by Authenticators results in SEGFAULT
-
Key: MESOS-2050
URL: https://issues.apache.org/jira/browse/MESOS-2050
Project: Mesos
Issue Type: Bug
Affects Versions: 0.21.0
Reporter: Vinod Kone
Assignee: Till Toenshoff
Fix For: 0.21.0, 0.22.0
Observed this on ASF CI:
Basically, as part of the recent Auth refactor for modules, the loading of
secrets is being done once per Authenticator Process instead of once in the
Master. Since, InMemoryAuxProp plugin manipulates static variables (e.g,
'properties') it results in SEGFAULT when one Authenticator (e.g., for slave)
does load() while another Authenticator (e.g., for framework) does lookup(),
as both these methods manipulate static 'properties'.
{code}
[ RUN ] MasterTest.LaunchDuplicateOfferTest
Using temporary directory '/tmp/MasterTest_LaunchDuplicateOfferTest_XEBbvp'
I1104 03:37:55.523553 28363 leveldb.cpp:176] Opened db in 2.270387ms
I1104 03:37:55.524250 28363 leveldb.cpp:183] Compacted db in 662527ns
I1104 03:37:55.524276 28363 leveldb.cpp:198] Created db iterator in 4964ns
I1104 03:37:55.524284 28363 leveldb.cpp:204] Seeked to beginning of db in
702ns
I1104 03:37:55.524291 28363 leveldb.cpp:273] Iterated through 0 keys in the
db in 450ns
I1104 03:37:55.524333 28363 replica.cpp:741] Replica recovered with log
positions 0 - 0 with 1 holes and 0 unlearned
I1104 03:37:55.524852 28384 recover.cpp:437] Starting replica recovery
I1104 03:37:55.525188 28384 recover.cpp:463] Replica is in EMPTY status
I1104 03:37:55.526577 28378 replica.cpp:638] Replica in EMPTY status received
a broadcasted recover request
I1104 03:37:55.527135 28378 master.cpp:318] Master
20141104-033755-3176252227-49988-28363 (proserpina.apache.org) started on
67.195.81.189:49988
I1104 03:37:55.527180 28378 master.cpp:364] Master only allowing
authenticated frameworks to register
I1104 03:37:55.527191 28378 master.cpp:369] Master only allowing
authenticated slaves to register
I1104 03:37:55.527217 28378 credentials.hpp:36] Loading credentials for
authentication from
'/tmp/MasterTest_LaunchDuplicateOfferTest_XEBbvp/credentials'
I1104 03:37:55.527451 28378 master.cpp:408] Authorization enabled
I1104 03:37:55.528081 28384 master.cpp:126] No whitelist given. Advertising
offers for all slaves
I1104 03:37:55.528548 28383 recover.cpp:188] Received a recover response from
a replica in EMPTY status
I1104 03:37:55.528645 28388 hierarchical_allocator_process.hpp:299]
Initializing hierarchical allocator process with master :
master@67.195.81.189:49988
I1104 03:37:55.529233 28388 master.cpp:1258] The newly elected leader is
master@67.195.81.189:49988 with id 20141104-033755-3176252227-49988-28363
I1104 03:37:55.529266 28388 master.cpp:1271] Elected as the leading master!
I1104 03:37:55.529289 28388 master.cpp:1089] Recovering from registrar
I1104 03:37:55.529311 28385 recover.cpp:554] Updating replica status to
STARTING
I1104 03:37:55.529500 28384 registrar.cpp:313] Recovering registrar
I1104 03:37:55.530037 28383 leveldb.cpp:306] Persisting metadata (8 bytes) to
leveldb took 497965ns
I1104 03:37:55.530083 28383 replica.cpp:320] Persisted replica status to
STARTING
I1104 03:37:55.530335 28387 recover.cpp:463] Replica is in STARTING status
I1104 03:37:55.531343 28381 replica.cpp:638] Replica in STARTING status
received a broadcasted recover request
I1104 03:37:55.531739 28384 recover.cpp:188] Received a recover response from
a replica in STARTING status
I1104 03:37:55.532168 28379 recover.cpp:554] Updating replica status to VOTING
I1104 03:37:55.532572 28381 leveldb.cpp:306] Persisting metadata (8 bytes) to
leveldb took 293974ns
I1104 03:37:55.532594 28381 replica.cpp:320] Persisted replica status to
VOTING
I1104 03:37:55.532790 28390 recover.cpp:568] Successfully joined the Paxos
group
I1104 03:37:55.533107 28390 recover.cpp:452] Recover process terminated
I1104 03:37:55.533604 28382 log.cpp:656] Attempting to start the writer
I1104 03:37:55.534840 28381 replica.cpp:474] Replica received implicit
promise request with proposal 1
I1104 03:37:55.535188 28381 leveldb.cpp:306] Persisting metadata (8 bytes) to
leveldb took 321021ns
I1104 03:37:55.535212 28381 replica.cpp:342] Persisted promised to 1
I1104 03:37:55.535893 28378 coordinator.cpp:230] Coordinator attemping to
fill missing position
I1104 03:37:55.537318 28392 replica.cpp:375] Replica received explicit
[jira] [Commented] (MESOS-2050) InMemoryAuxProp plugin used by Authenticators results in SEGFAULT
[
https://issues.apache.org/jira/browse/MESOS-2050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14285655#comment-14285655
]
Till Toenshoff commented on MESOS-2050:
---
- fixed auxmem-plugin stackup
- fixed possible issue triggered by running multiple masters concurrently (load
/ lookup RW access to properties)
Updated the original RR to include all fixes:
https://reviews.apache.org/r/27760/.
InMemoryAuxProp plugin used by Authenticators results in SEGFAULT
-
Key: MESOS-2050
URL: https://issues.apache.org/jira/browse/MESOS-2050
Project: Mesos
Issue Type: Bug
Affects Versions: 0.21.0
Reporter: Vinod Kone
Assignee: Till Toenshoff
Fix For: 0.21.0
Observed this on ASF CI:
Basically, as part of the recent Auth refactor for modules, the loading of
secrets is being done once per Authenticator Process instead of once in the
Master. Since, InMemoryAuxProp plugin manipulates static variables (e.g,
'properties') it results in SEGFAULT when one Authenticator (e.g., for slave)
does load() while another Authenticator (e.g., for framework) does lookup(),
as both these methods manipulate static 'properties'.
{code}
[ RUN ] MasterTest.LaunchDuplicateOfferTest
Using temporary directory '/tmp/MasterTest_LaunchDuplicateOfferTest_XEBbvp'
I1104 03:37:55.523553 28363 leveldb.cpp:176] Opened db in 2.270387ms
I1104 03:37:55.524250 28363 leveldb.cpp:183] Compacted db in 662527ns
I1104 03:37:55.524276 28363 leveldb.cpp:198] Created db iterator in 4964ns
I1104 03:37:55.524284 28363 leveldb.cpp:204] Seeked to beginning of db in
702ns
I1104 03:37:55.524291 28363 leveldb.cpp:273] Iterated through 0 keys in the
db in 450ns
I1104 03:37:55.524333 28363 replica.cpp:741] Replica recovered with log
positions 0 - 0 with 1 holes and 0 unlearned
I1104 03:37:55.524852 28384 recover.cpp:437] Starting replica recovery
I1104 03:37:55.525188 28384 recover.cpp:463] Replica is in EMPTY status
I1104 03:37:55.526577 28378 replica.cpp:638] Replica in EMPTY status received
a broadcasted recover request
I1104 03:37:55.527135 28378 master.cpp:318] Master
20141104-033755-3176252227-49988-28363 (proserpina.apache.org) started on
67.195.81.189:49988
I1104 03:37:55.527180 28378 master.cpp:364] Master only allowing
authenticated frameworks to register
I1104 03:37:55.527191 28378 master.cpp:369] Master only allowing
authenticated slaves to register
I1104 03:37:55.527217 28378 credentials.hpp:36] Loading credentials for
authentication from
'/tmp/MasterTest_LaunchDuplicateOfferTest_XEBbvp/credentials'
I1104 03:37:55.527451 28378 master.cpp:408] Authorization enabled
I1104 03:37:55.528081 28384 master.cpp:126] No whitelist given. Advertising
offers for all slaves
I1104 03:37:55.528548 28383 recover.cpp:188] Received a recover response from
a replica in EMPTY status
I1104 03:37:55.528645 28388 hierarchical_allocator_process.hpp:299]
Initializing hierarchical allocator process with master :
master@67.195.81.189:49988
I1104 03:37:55.529233 28388 master.cpp:1258] The newly elected leader is
master@67.195.81.189:49988 with id 20141104-033755-3176252227-49988-28363
I1104 03:37:55.529266 28388 master.cpp:1271] Elected as the leading master!
I1104 03:37:55.529289 28388 master.cpp:1089] Recovering from registrar
I1104 03:37:55.529311 28385 recover.cpp:554] Updating replica status to
STARTING
I1104 03:37:55.529500 28384 registrar.cpp:313] Recovering registrar
I1104 03:37:55.530037 28383 leveldb.cpp:306] Persisting metadata (8 bytes) to
leveldb took 497965ns
I1104 03:37:55.530083 28383 replica.cpp:320] Persisted replica status to
STARTING
I1104 03:37:55.530335 28387 recover.cpp:463] Replica is in STARTING status
I1104 03:37:55.531343 28381 replica.cpp:638] Replica in STARTING status
received a broadcasted recover request
I1104 03:37:55.531739 28384 recover.cpp:188] Received a recover response from
a replica in STARTING status
I1104 03:37:55.532168 28379 recover.cpp:554] Updating replica status to VOTING
I1104 03:37:55.532572 28381 leveldb.cpp:306] Persisting metadata (8 bytes) to
leveldb took 293974ns
I1104 03:37:55.532594 28381 replica.cpp:320] Persisted replica status to
VOTING
I1104 03:37:55.532790 28390 recover.cpp:568] Successfully joined the Paxos
group
I1104 03:37:55.533107 28390 recover.cpp:452] Recover process terminated
I1104 03:37:55.533604 28382 log.cpp:656] Attempting to start the writer
I1104 03:37:55.534840 28381 replica.cpp:474] Replica received implicit
promise request with proposal 1
I1104 03:37:55.535188 28381 leveldb.cpp:306] Persisting metadata (8 bytes) to
leveldb took 321021ns
I1104 03:37:55.535212 28381 replica.cpp:342] Persisted promised to 1
I1104 03:37:55.535893 28378 coordinator.cpp:230]
[jira] [Commented] (MESOS-2050) InMemoryAuxProp plugin used by Authenticators results in SEGFAULT
[
https://issues.apache.org/jira/browse/MESOS-2050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14277079#comment-14277079
]
Till Toenshoff commented on MESOS-2050:
---
This patch has triggered a new issue - sorry for that. I am still investigating
and will asap propose a fix.
InMemoryAuxProp plugin used by Authenticators results in SEGFAULT
-
Key: MESOS-2050
URL: https://issues.apache.org/jira/browse/MESOS-2050
Project: Mesos
Issue Type: Bug
Affects Versions: 0.21.0
Reporter: Vinod Kone
Assignee: Till Toenshoff
Fix For: 0.21.0
Observed this on ASF CI:
Basically, as part of the recent Auth refactor for modules, the loading of
secrets is being done once per Authenticator Process instead of once in the
Master. Since, InMemoryAuxProp plugin manipulates static variables (e.g,
'properties') it results in SEGFAULT when one Authenticator (e.g., for slave)
does load() while another Authenticator (e.g., for framework) does lookup(),
as both these methods manipulate static 'properties'.
{code}
[ RUN ] MasterTest.LaunchDuplicateOfferTest
Using temporary directory '/tmp/MasterTest_LaunchDuplicateOfferTest_XEBbvp'
I1104 03:37:55.523553 28363 leveldb.cpp:176] Opened db in 2.270387ms
I1104 03:37:55.524250 28363 leveldb.cpp:183] Compacted db in 662527ns
I1104 03:37:55.524276 28363 leveldb.cpp:198] Created db iterator in 4964ns
I1104 03:37:55.524284 28363 leveldb.cpp:204] Seeked to beginning of db in
702ns
I1104 03:37:55.524291 28363 leveldb.cpp:273] Iterated through 0 keys in the
db in 450ns
I1104 03:37:55.524333 28363 replica.cpp:741] Replica recovered with log
positions 0 - 0 with 1 holes and 0 unlearned
I1104 03:37:55.524852 28384 recover.cpp:437] Starting replica recovery
I1104 03:37:55.525188 28384 recover.cpp:463] Replica is in EMPTY status
I1104 03:37:55.526577 28378 replica.cpp:638] Replica in EMPTY status received
a broadcasted recover request
I1104 03:37:55.527135 28378 master.cpp:318] Master
20141104-033755-3176252227-49988-28363 (proserpina.apache.org) started on
67.195.81.189:49988
I1104 03:37:55.527180 28378 master.cpp:364] Master only allowing
authenticated frameworks to register
I1104 03:37:55.527191 28378 master.cpp:369] Master only allowing
authenticated slaves to register
I1104 03:37:55.527217 28378 credentials.hpp:36] Loading credentials for
authentication from
'/tmp/MasterTest_LaunchDuplicateOfferTest_XEBbvp/credentials'
I1104 03:37:55.527451 28378 master.cpp:408] Authorization enabled
I1104 03:37:55.528081 28384 master.cpp:126] No whitelist given. Advertising
offers for all slaves
I1104 03:37:55.528548 28383 recover.cpp:188] Received a recover response from
a replica in EMPTY status
I1104 03:37:55.528645 28388 hierarchical_allocator_process.hpp:299]
Initializing hierarchical allocator process with master :
master@67.195.81.189:49988
I1104 03:37:55.529233 28388 master.cpp:1258] The newly elected leader is
master@67.195.81.189:49988 with id 20141104-033755-3176252227-49988-28363
I1104 03:37:55.529266 28388 master.cpp:1271] Elected as the leading master!
I1104 03:37:55.529289 28388 master.cpp:1089] Recovering from registrar
I1104 03:37:55.529311 28385 recover.cpp:554] Updating replica status to
STARTING
I1104 03:37:55.529500 28384 registrar.cpp:313] Recovering registrar
I1104 03:37:55.530037 28383 leveldb.cpp:306] Persisting metadata (8 bytes) to
leveldb took 497965ns
I1104 03:37:55.530083 28383 replica.cpp:320] Persisted replica status to
STARTING
I1104 03:37:55.530335 28387 recover.cpp:463] Replica is in STARTING status
I1104 03:37:55.531343 28381 replica.cpp:638] Replica in STARTING status
received a broadcasted recover request
I1104 03:37:55.531739 28384 recover.cpp:188] Received a recover response from
a replica in STARTING status
I1104 03:37:55.532168 28379 recover.cpp:554] Updating replica status to VOTING
I1104 03:37:55.532572 28381 leveldb.cpp:306] Persisting metadata (8 bytes) to
leveldb took 293974ns
I1104 03:37:55.532594 28381 replica.cpp:320] Persisted replica status to
VOTING
I1104 03:37:55.532790 28390 recover.cpp:568] Successfully joined the Paxos
group
I1104 03:37:55.533107 28390 recover.cpp:452] Recover process terminated
I1104 03:37:55.533604 28382 log.cpp:656] Attempting to start the writer
I1104 03:37:55.534840 28381 replica.cpp:474] Replica received implicit
promise request with proposal 1
I1104 03:37:55.535188 28381 leveldb.cpp:306] Persisting metadata (8 bytes) to
leveldb took 321021ns
I1104 03:37:55.535212 28381 replica.cpp:342] Persisted promised to 1
I1104 03:37:55.535893 28378 coordinator.cpp:230] Coordinator attemping to
fill missing position
I1104 03:37:55.537318 28392 replica.cpp:375] Replica received explicit
[jira] [Commented] (MESOS-2050) InMemoryAuxProp plugin used by Authenticators results in SEGFAULT
[
https://issues.apache.org/jira/browse/MESOS-2050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14277278#comment-14277278
]
Till Toenshoff commented on MESOS-2050:
---
https://reviews.apache.org/r/29887/
InMemoryAuxProp plugin used by Authenticators results in SEGFAULT
-
Key: MESOS-2050
URL: https://issues.apache.org/jira/browse/MESOS-2050
Project: Mesos
Issue Type: Bug
Affects Versions: 0.21.0
Reporter: Vinod Kone
Assignee: Till Toenshoff
Fix For: 0.21.0
Observed this on ASF CI:
Basically, as part of the recent Auth refactor for modules, the loading of
secrets is being done once per Authenticator Process instead of once in the
Master. Since, InMemoryAuxProp plugin manipulates static variables (e.g,
'properties') it results in SEGFAULT when one Authenticator (e.g., for slave)
does load() while another Authenticator (e.g., for framework) does lookup(),
as both these methods manipulate static 'properties'.
{code}
[ RUN ] MasterTest.LaunchDuplicateOfferTest
Using temporary directory '/tmp/MasterTest_LaunchDuplicateOfferTest_XEBbvp'
I1104 03:37:55.523553 28363 leveldb.cpp:176] Opened db in 2.270387ms
I1104 03:37:55.524250 28363 leveldb.cpp:183] Compacted db in 662527ns
I1104 03:37:55.524276 28363 leveldb.cpp:198] Created db iterator in 4964ns
I1104 03:37:55.524284 28363 leveldb.cpp:204] Seeked to beginning of db in
702ns
I1104 03:37:55.524291 28363 leveldb.cpp:273] Iterated through 0 keys in the
db in 450ns
I1104 03:37:55.524333 28363 replica.cpp:741] Replica recovered with log
positions 0 - 0 with 1 holes and 0 unlearned
I1104 03:37:55.524852 28384 recover.cpp:437] Starting replica recovery
I1104 03:37:55.525188 28384 recover.cpp:463] Replica is in EMPTY status
I1104 03:37:55.526577 28378 replica.cpp:638] Replica in EMPTY status received
a broadcasted recover request
I1104 03:37:55.527135 28378 master.cpp:318] Master
20141104-033755-3176252227-49988-28363 (proserpina.apache.org) started on
67.195.81.189:49988
I1104 03:37:55.527180 28378 master.cpp:364] Master only allowing
authenticated frameworks to register
I1104 03:37:55.527191 28378 master.cpp:369] Master only allowing
authenticated slaves to register
I1104 03:37:55.527217 28378 credentials.hpp:36] Loading credentials for
authentication from
'/tmp/MasterTest_LaunchDuplicateOfferTest_XEBbvp/credentials'
I1104 03:37:55.527451 28378 master.cpp:408] Authorization enabled
I1104 03:37:55.528081 28384 master.cpp:126] No whitelist given. Advertising
offers for all slaves
I1104 03:37:55.528548 28383 recover.cpp:188] Received a recover response from
a replica in EMPTY status
I1104 03:37:55.528645 28388 hierarchical_allocator_process.hpp:299]
Initializing hierarchical allocator process with master :
master@67.195.81.189:49988
I1104 03:37:55.529233 28388 master.cpp:1258] The newly elected leader is
master@67.195.81.189:49988 with id 20141104-033755-3176252227-49988-28363
I1104 03:37:55.529266 28388 master.cpp:1271] Elected as the leading master!
I1104 03:37:55.529289 28388 master.cpp:1089] Recovering from registrar
I1104 03:37:55.529311 28385 recover.cpp:554] Updating replica status to
STARTING
I1104 03:37:55.529500 28384 registrar.cpp:313] Recovering registrar
I1104 03:37:55.530037 28383 leveldb.cpp:306] Persisting metadata (8 bytes) to
leveldb took 497965ns
I1104 03:37:55.530083 28383 replica.cpp:320] Persisted replica status to
STARTING
I1104 03:37:55.530335 28387 recover.cpp:463] Replica is in STARTING status
I1104 03:37:55.531343 28381 replica.cpp:638] Replica in STARTING status
received a broadcasted recover request
I1104 03:37:55.531739 28384 recover.cpp:188] Received a recover response from
a replica in STARTING status
I1104 03:37:55.532168 28379 recover.cpp:554] Updating replica status to VOTING
I1104 03:37:55.532572 28381 leveldb.cpp:306] Persisting metadata (8 bytes) to
leveldb took 293974ns
I1104 03:37:55.532594 28381 replica.cpp:320] Persisted replica status to
VOTING
I1104 03:37:55.532790 28390 recover.cpp:568] Successfully joined the Paxos
group
I1104 03:37:55.533107 28390 recover.cpp:452] Recover process terminated
I1104 03:37:55.533604 28382 log.cpp:656] Attempting to start the writer
I1104 03:37:55.534840 28381 replica.cpp:474] Replica received implicit
promise request with proposal 1
I1104 03:37:55.535188 28381 leveldb.cpp:306] Persisting metadata (8 bytes) to
leveldb took 321021ns
I1104 03:37:55.535212 28381 replica.cpp:342] Persisted promised to 1
I1104 03:37:55.535893 28378 coordinator.cpp:230] Coordinator attemping to
fill missing position
I1104 03:37:55.537318 28392 replica.cpp:375] Replica received explicit
promise request for position 0 with proposal 2
I1104 03:37:55.537719
[jira] [Commented] (MESOS-2050) InMemoryAuxProp plugin used by Authenticators results in SEGFAULT
[
https://issues.apache.org/jira/browse/MESOS-2050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14277281#comment-14277281
]
Till Toenshoff commented on MESOS-2050:
---
https://reviews.apache.org/r/29887/
InMemoryAuxProp plugin used by Authenticators results in SEGFAULT
-
Key: MESOS-2050
URL: https://issues.apache.org/jira/browse/MESOS-2050
Project: Mesos
Issue Type: Bug
Affects Versions: 0.21.0
Reporter: Vinod Kone
Assignee: Till Toenshoff
Fix For: 0.21.0
Observed this on ASF CI:
Basically, as part of the recent Auth refactor for modules, the loading of
secrets is being done once per Authenticator Process instead of once in the
Master. Since, InMemoryAuxProp plugin manipulates static variables (e.g,
'properties') it results in SEGFAULT when one Authenticator (e.g., for slave)
does load() while another Authenticator (e.g., for framework) does lookup(),
as both these methods manipulate static 'properties'.
{code}
[ RUN ] MasterTest.LaunchDuplicateOfferTest
Using temporary directory '/tmp/MasterTest_LaunchDuplicateOfferTest_XEBbvp'
I1104 03:37:55.523553 28363 leveldb.cpp:176] Opened db in 2.270387ms
I1104 03:37:55.524250 28363 leveldb.cpp:183] Compacted db in 662527ns
I1104 03:37:55.524276 28363 leveldb.cpp:198] Created db iterator in 4964ns
I1104 03:37:55.524284 28363 leveldb.cpp:204] Seeked to beginning of db in
702ns
I1104 03:37:55.524291 28363 leveldb.cpp:273] Iterated through 0 keys in the
db in 450ns
I1104 03:37:55.524333 28363 replica.cpp:741] Replica recovered with log
positions 0 - 0 with 1 holes and 0 unlearned
I1104 03:37:55.524852 28384 recover.cpp:437] Starting replica recovery
I1104 03:37:55.525188 28384 recover.cpp:463] Replica is in EMPTY status
I1104 03:37:55.526577 28378 replica.cpp:638] Replica in EMPTY status received
a broadcasted recover request
I1104 03:37:55.527135 28378 master.cpp:318] Master
20141104-033755-3176252227-49988-28363 (proserpina.apache.org) started on
67.195.81.189:49988
I1104 03:37:55.527180 28378 master.cpp:364] Master only allowing
authenticated frameworks to register
I1104 03:37:55.527191 28378 master.cpp:369] Master only allowing
authenticated slaves to register
I1104 03:37:55.527217 28378 credentials.hpp:36] Loading credentials for
authentication from
'/tmp/MasterTest_LaunchDuplicateOfferTest_XEBbvp/credentials'
I1104 03:37:55.527451 28378 master.cpp:408] Authorization enabled
I1104 03:37:55.528081 28384 master.cpp:126] No whitelist given. Advertising
offers for all slaves
I1104 03:37:55.528548 28383 recover.cpp:188] Received a recover response from
a replica in EMPTY status
I1104 03:37:55.528645 28388 hierarchical_allocator_process.hpp:299]
Initializing hierarchical allocator process with master :
master@67.195.81.189:49988
I1104 03:37:55.529233 28388 master.cpp:1258] The newly elected leader is
master@67.195.81.189:49988 with id 20141104-033755-3176252227-49988-28363
I1104 03:37:55.529266 28388 master.cpp:1271] Elected as the leading master!
I1104 03:37:55.529289 28388 master.cpp:1089] Recovering from registrar
I1104 03:37:55.529311 28385 recover.cpp:554] Updating replica status to
STARTING
I1104 03:37:55.529500 28384 registrar.cpp:313] Recovering registrar
I1104 03:37:55.530037 28383 leveldb.cpp:306] Persisting metadata (8 bytes) to
leveldb took 497965ns
I1104 03:37:55.530083 28383 replica.cpp:320] Persisted replica status to
STARTING
I1104 03:37:55.530335 28387 recover.cpp:463] Replica is in STARTING status
I1104 03:37:55.531343 28381 replica.cpp:638] Replica in STARTING status
received a broadcasted recover request
I1104 03:37:55.531739 28384 recover.cpp:188] Received a recover response from
a replica in STARTING status
I1104 03:37:55.532168 28379 recover.cpp:554] Updating replica status to VOTING
I1104 03:37:55.532572 28381 leveldb.cpp:306] Persisting metadata (8 bytes) to
leveldb took 293974ns
I1104 03:37:55.532594 28381 replica.cpp:320] Persisted replica status to
VOTING
I1104 03:37:55.532790 28390 recover.cpp:568] Successfully joined the Paxos
group
I1104 03:37:55.533107 28390 recover.cpp:452] Recover process terminated
I1104 03:37:55.533604 28382 log.cpp:656] Attempting to start the writer
I1104 03:37:55.534840 28381 replica.cpp:474] Replica received implicit
promise request with proposal 1
I1104 03:37:55.535188 28381 leveldb.cpp:306] Persisting metadata (8 bytes) to
leveldb took 321021ns
I1104 03:37:55.535212 28381 replica.cpp:342] Persisted promised to 1
I1104 03:37:55.535893 28378 coordinator.cpp:230] Coordinator attemping to
fill missing position
I1104 03:37:55.537318 28392 replica.cpp:375] Replica received explicit
promise request for position 0 with proposal 2
I1104 03:37:55.537719
[jira] [Commented] (MESOS-2050) InMemoryAuxProp plugin used by Authenticators results in SEGFAULT
[
https://issues.apache.org/jira/browse/MESOS-2050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14276637#comment-14276637
]
Adam B commented on MESOS-2050:
---
Committed the proper (non-bandaid) approach:
commit 03ce326887edd1f8718b3b60e9c81b3bf063ef64
Author: Till Toenshoff toensh...@me.com
Date: Tue Jan 13 23:03:28 2015 -0800
Revised authenticator interface to allow for two fold implementations.
The initial design and implementation of the authenticator module
interface caused issues and was not optimal for heavy lifting setup of
external dependencies. By introducing a two fold design, this has been
decoupled from the authentication message processing. The new design
also gets us back on track to the goal of makeing SASL a soft
dependency of mesos.
Review: https://reviews.apache.org/r/27760
InMemoryAuxProp plugin used by Authenticators results in SEGFAULT
-
Key: MESOS-2050
URL: https://issues.apache.org/jira/browse/MESOS-2050
Project: Mesos
Issue Type: Bug
Affects Versions: 0.21.0
Reporter: Vinod Kone
Assignee: Till Toenshoff
Fix For: 0.21.0
Observed this on ASF CI:
Basically, as part of the recent Auth refactor for modules, the loading of
secrets is being done once per Authenticator Process instead of once in the
Master. Since, InMemoryAuxProp plugin manipulates static variables (e.g,
'properties') it results in SEGFAULT when one Authenticator (e.g., for slave)
does load() while another Authenticator (e.g., for framework) does lookup(),
as both these methods manipulate static 'properties'.
{code}
[ RUN ] MasterTest.LaunchDuplicateOfferTest
Using temporary directory '/tmp/MasterTest_LaunchDuplicateOfferTest_XEBbvp'
I1104 03:37:55.523553 28363 leveldb.cpp:176] Opened db in 2.270387ms
I1104 03:37:55.524250 28363 leveldb.cpp:183] Compacted db in 662527ns
I1104 03:37:55.524276 28363 leveldb.cpp:198] Created db iterator in 4964ns
I1104 03:37:55.524284 28363 leveldb.cpp:204] Seeked to beginning of db in
702ns
I1104 03:37:55.524291 28363 leveldb.cpp:273] Iterated through 0 keys in the
db in 450ns
I1104 03:37:55.524333 28363 replica.cpp:741] Replica recovered with log
positions 0 - 0 with 1 holes and 0 unlearned
I1104 03:37:55.524852 28384 recover.cpp:437] Starting replica recovery
I1104 03:37:55.525188 28384 recover.cpp:463] Replica is in EMPTY status
I1104 03:37:55.526577 28378 replica.cpp:638] Replica in EMPTY status received
a broadcasted recover request
I1104 03:37:55.527135 28378 master.cpp:318] Master
20141104-033755-3176252227-49988-28363 (proserpina.apache.org) started on
67.195.81.189:49988
I1104 03:37:55.527180 28378 master.cpp:364] Master only allowing
authenticated frameworks to register
I1104 03:37:55.527191 28378 master.cpp:369] Master only allowing
authenticated slaves to register
I1104 03:37:55.527217 28378 credentials.hpp:36] Loading credentials for
authentication from
'/tmp/MasterTest_LaunchDuplicateOfferTest_XEBbvp/credentials'
I1104 03:37:55.527451 28378 master.cpp:408] Authorization enabled
I1104 03:37:55.528081 28384 master.cpp:126] No whitelist given. Advertising
offers for all slaves
I1104 03:37:55.528548 28383 recover.cpp:188] Received a recover response from
a replica in EMPTY status
I1104 03:37:55.528645 28388 hierarchical_allocator_process.hpp:299]
Initializing hierarchical allocator process with master :
master@67.195.81.189:49988
I1104 03:37:55.529233 28388 master.cpp:1258] The newly elected leader is
master@67.195.81.189:49988 with id 20141104-033755-3176252227-49988-28363
I1104 03:37:55.529266 28388 master.cpp:1271] Elected as the leading master!
I1104 03:37:55.529289 28388 master.cpp:1089] Recovering from registrar
I1104 03:37:55.529311 28385 recover.cpp:554] Updating replica status to
STARTING
I1104 03:37:55.529500 28384 registrar.cpp:313] Recovering registrar
I1104 03:37:55.530037 28383 leveldb.cpp:306] Persisting metadata (8 bytes) to
leveldb took 497965ns
I1104 03:37:55.530083 28383 replica.cpp:320] Persisted replica status to
STARTING
I1104 03:37:55.530335 28387 recover.cpp:463] Replica is in STARTING status
I1104 03:37:55.531343 28381 replica.cpp:638] Replica in STARTING status
received a broadcasted recover request
I1104 03:37:55.531739 28384 recover.cpp:188] Received a recover response from
a replica in STARTING status
I1104 03:37:55.532168 28379 recover.cpp:554] Updating replica status to VOTING
I1104 03:37:55.532572 28381 leveldb.cpp:306] Persisting metadata (8 bytes) to
leveldb took 293974ns
I1104 03:37:55.532594 28381 replica.cpp:320] Persisted replica status to
VOTING
I1104 03:37:55.532790 28390 recover.cpp:568] Successfully joined the Paxos
group
I1104 03:37:55.533107 28390
[jira] [Commented] (MESOS-2050) InMemoryAuxProp plugin used by Authenticators results in SEGFAULT
[
https://issues.apache.org/jira/browse/MESOS-2050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14201770#comment-14201770
]
Till Toenshoff commented on MESOS-2050:
---
Trouble is that modules can not handle static methods. I initially had a
proposal for covering that but it wasn't really scaling well (versioning
issues), hence we decided to drop that approach. I will figure out a solution
that makes everyone happy without pulling something out of the heavy duty mutex
drawer
InMemoryAuxProp plugin used by Authenticators results in SEGFAULT
-
Key: MESOS-2050
URL: https://issues.apache.org/jira/browse/MESOS-2050
Project: Mesos
Issue Type: Bug
Affects Versions: 0.21.0
Reporter: Vinod Kone
Observed this on ASF CI:
Basically, as part of the recent Auth refactor for modules, the loading of
secrets is being done once per Authenticator Process instead of once in the
Master. Since, InMemoryAuxProp plugin manipulates static variables (e.g,
'properties') it results in SEGFAULT when one Authenticator (e.g., for slave)
does load() while another Authenticator (e.g., for framework) does lookup(),
as both these methods manipulate static 'properties'.
{code}
[ RUN ] MasterTest.LaunchDuplicateOfferTest
Using temporary directory '/tmp/MasterTest_LaunchDuplicateOfferTest_XEBbvp'
I1104 03:37:55.523553 28363 leveldb.cpp:176] Opened db in 2.270387ms
I1104 03:37:55.524250 28363 leveldb.cpp:183] Compacted db in 662527ns
I1104 03:37:55.524276 28363 leveldb.cpp:198] Created db iterator in 4964ns
I1104 03:37:55.524284 28363 leveldb.cpp:204] Seeked to beginning of db in
702ns
I1104 03:37:55.524291 28363 leveldb.cpp:273] Iterated through 0 keys in the
db in 450ns
I1104 03:37:55.524333 28363 replica.cpp:741] Replica recovered with log
positions 0 - 0 with 1 holes and 0 unlearned
I1104 03:37:55.524852 28384 recover.cpp:437] Starting replica recovery
I1104 03:37:55.525188 28384 recover.cpp:463] Replica is in EMPTY status
I1104 03:37:55.526577 28378 replica.cpp:638] Replica in EMPTY status received
a broadcasted recover request
I1104 03:37:55.527135 28378 master.cpp:318] Master
20141104-033755-3176252227-49988-28363 (proserpina.apache.org) started on
67.195.81.189:49988
I1104 03:37:55.527180 28378 master.cpp:364] Master only allowing
authenticated frameworks to register
I1104 03:37:55.527191 28378 master.cpp:369] Master only allowing
authenticated slaves to register
I1104 03:37:55.527217 28378 credentials.hpp:36] Loading credentials for
authentication from
'/tmp/MasterTest_LaunchDuplicateOfferTest_XEBbvp/credentials'
I1104 03:37:55.527451 28378 master.cpp:408] Authorization enabled
I1104 03:37:55.528081 28384 master.cpp:126] No whitelist given. Advertising
offers for all slaves
I1104 03:37:55.528548 28383 recover.cpp:188] Received a recover response from
a replica in EMPTY status
I1104 03:37:55.528645 28388 hierarchical_allocator_process.hpp:299]
Initializing hierarchical allocator process with master :
master@67.195.81.189:49988
I1104 03:37:55.529233 28388 master.cpp:1258] The newly elected leader is
master@67.195.81.189:49988 with id 20141104-033755-3176252227-49988-28363
I1104 03:37:55.529266 28388 master.cpp:1271] Elected as the leading master!
I1104 03:37:55.529289 28388 master.cpp:1089] Recovering from registrar
I1104 03:37:55.529311 28385 recover.cpp:554] Updating replica status to
STARTING
I1104 03:37:55.529500 28384 registrar.cpp:313] Recovering registrar
I1104 03:37:55.530037 28383 leveldb.cpp:306] Persisting metadata (8 bytes) to
leveldb took 497965ns
I1104 03:37:55.530083 28383 replica.cpp:320] Persisted replica status to
STARTING
I1104 03:37:55.530335 28387 recover.cpp:463] Replica is in STARTING status
I1104 03:37:55.531343 28381 replica.cpp:638] Replica in STARTING status
received a broadcasted recover request
I1104 03:37:55.531739 28384 recover.cpp:188] Received a recover response from
a replica in STARTING status
I1104 03:37:55.532168 28379 recover.cpp:554] Updating replica status to VOTING
I1104 03:37:55.532572 28381 leveldb.cpp:306] Persisting metadata (8 bytes) to
leveldb took 293974ns
I1104 03:37:55.532594 28381 replica.cpp:320] Persisted replica status to
VOTING
I1104 03:37:55.532790 28390 recover.cpp:568] Successfully joined the Paxos
group
I1104 03:37:55.533107 28390 recover.cpp:452] Recover process terminated
I1104 03:37:55.533604 28382 log.cpp:656] Attempting to start the writer
I1104 03:37:55.534840 28381 replica.cpp:474] Replica received implicit
promise request with proposal 1
I1104 03:37:55.535188 28381 leveldb.cpp:306] Persisting metadata (8 bytes) to
leveldb took 321021ns
I1104 03:37:55.535212 28381 replica.cpp:342] Persisted promised to 1
I1104 03:37:55.535893 28378
[jira] [Commented] (MESOS-2050) InMemoryAuxProp plugin used by Authenticators results in SEGFAULT
[
https://issues.apache.org/jira/browse/MESOS-2050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14203060#comment-14203060
]
Till Toenshoff commented on MESOS-2050:
---
commit ce82e81c12d7f91b158c73465c47725331626f32
Author: Till Toenshoff toensh...@me.com
Date: Sat Nov 8 01:19:50 2014 +0100
Fixed Authenticator SASL auxiliary memory access.
Review: https://reviews.apache.org/r/27741
InMemoryAuxProp plugin used by Authenticators results in SEGFAULT
-
Key: MESOS-2050
URL: https://issues.apache.org/jira/browse/MESOS-2050
Project: Mesos
Issue Type: Bug
Affects Versions: 0.21.0
Reporter: Vinod Kone
Assignee: Till Toenshoff
Observed this on ASF CI:
Basically, as part of the recent Auth refactor for modules, the loading of
secrets is being done once per Authenticator Process instead of once in the
Master. Since, InMemoryAuxProp plugin manipulates static variables (e.g,
'properties') it results in SEGFAULT when one Authenticator (e.g., for slave)
does load() while another Authenticator (e.g., for framework) does lookup(),
as both these methods manipulate static 'properties'.
{code}
[ RUN ] MasterTest.LaunchDuplicateOfferTest
Using temporary directory '/tmp/MasterTest_LaunchDuplicateOfferTest_XEBbvp'
I1104 03:37:55.523553 28363 leveldb.cpp:176] Opened db in 2.270387ms
I1104 03:37:55.524250 28363 leveldb.cpp:183] Compacted db in 662527ns
I1104 03:37:55.524276 28363 leveldb.cpp:198] Created db iterator in 4964ns
I1104 03:37:55.524284 28363 leveldb.cpp:204] Seeked to beginning of db in
702ns
I1104 03:37:55.524291 28363 leveldb.cpp:273] Iterated through 0 keys in the
db in 450ns
I1104 03:37:55.524333 28363 replica.cpp:741] Replica recovered with log
positions 0 - 0 with 1 holes and 0 unlearned
I1104 03:37:55.524852 28384 recover.cpp:437] Starting replica recovery
I1104 03:37:55.525188 28384 recover.cpp:463] Replica is in EMPTY status
I1104 03:37:55.526577 28378 replica.cpp:638] Replica in EMPTY status received
a broadcasted recover request
I1104 03:37:55.527135 28378 master.cpp:318] Master
20141104-033755-3176252227-49988-28363 (proserpina.apache.org) started on
67.195.81.189:49988
I1104 03:37:55.527180 28378 master.cpp:364] Master only allowing
authenticated frameworks to register
I1104 03:37:55.527191 28378 master.cpp:369] Master only allowing
authenticated slaves to register
I1104 03:37:55.527217 28378 credentials.hpp:36] Loading credentials for
authentication from
'/tmp/MasterTest_LaunchDuplicateOfferTest_XEBbvp/credentials'
I1104 03:37:55.527451 28378 master.cpp:408] Authorization enabled
I1104 03:37:55.528081 28384 master.cpp:126] No whitelist given. Advertising
offers for all slaves
I1104 03:37:55.528548 28383 recover.cpp:188] Received a recover response from
a replica in EMPTY status
I1104 03:37:55.528645 28388 hierarchical_allocator_process.hpp:299]
Initializing hierarchical allocator process with master :
master@67.195.81.189:49988
I1104 03:37:55.529233 28388 master.cpp:1258] The newly elected leader is
master@67.195.81.189:49988 with id 20141104-033755-3176252227-49988-28363
I1104 03:37:55.529266 28388 master.cpp:1271] Elected as the leading master!
I1104 03:37:55.529289 28388 master.cpp:1089] Recovering from registrar
I1104 03:37:55.529311 28385 recover.cpp:554] Updating replica status to
STARTING
I1104 03:37:55.529500 28384 registrar.cpp:313] Recovering registrar
I1104 03:37:55.530037 28383 leveldb.cpp:306] Persisting metadata (8 bytes) to
leveldb took 497965ns
I1104 03:37:55.530083 28383 replica.cpp:320] Persisted replica status to
STARTING
I1104 03:37:55.530335 28387 recover.cpp:463] Replica is in STARTING status
I1104 03:37:55.531343 28381 replica.cpp:638] Replica in STARTING status
received a broadcasted recover request
I1104 03:37:55.531739 28384 recover.cpp:188] Received a recover response from
a replica in STARTING status
I1104 03:37:55.532168 28379 recover.cpp:554] Updating replica status to VOTING
I1104 03:37:55.532572 28381 leveldb.cpp:306] Persisting metadata (8 bytes) to
leveldb took 293974ns
I1104 03:37:55.532594 28381 replica.cpp:320] Persisted replica status to
VOTING
I1104 03:37:55.532790 28390 recover.cpp:568] Successfully joined the Paxos
group
I1104 03:37:55.533107 28390 recover.cpp:452] Recover process terminated
I1104 03:37:55.533604 28382 log.cpp:656] Attempting to start the writer
I1104 03:37:55.534840 28381 replica.cpp:474] Replica received implicit
promise request with proposal 1
I1104 03:37:55.535188 28381 leveldb.cpp:306] Persisting metadata (8 bytes) to
leveldb took 321021ns
I1104 03:37:55.535212 28381 replica.cpp:342] Persisted promised to 1
I1104 03:37:55.535893 28378 coordinator.cpp:230] Coordinator attemping to
fill
[jira] [Commented] (MESOS-2050) InMemoryAuxProp plugin used by Authenticators results in SEGFAULT
[
https://issues.apache.org/jira/browse/MESOS-2050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14201516#comment-14201516
]
Vinod Kone commented on MESOS-2050:
---
The way InMemoryAuxProp is implemented I think it makes sense to pull back the
loading of credentials from within Authenticator initialize to master
initialize.
[~tillt] do you want to take this?
InMemoryAuxProp plugin used by Authenticators results in SEGFAULT
-
Key: MESOS-2050
URL: https://issues.apache.org/jira/browse/MESOS-2050
Project: Mesos
Issue Type: Bug
Affects Versions: 0.21.0
Reporter: Vinod Kone
Observed this on ASF CI:
Basically, as part of the recent Auth refactor for modules, the loading of
secrets is being done once per Authenticator Process instead of once in the
Master. Since, InMemoryAuxProp plugin manipulates static variables (e.g,
'properties') it results in SEGFAULT when one Authenticator (e.g., for slave)
does load() while another Authenticator (e.g., for framework) does lookup(),
as both these methods manipulate static 'properties'.
{code}
[ RUN ] MasterTest.LaunchDuplicateOfferTest
Using temporary directory '/tmp/MasterTest_LaunchDuplicateOfferTest_XEBbvp'
I1104 03:37:55.523553 28363 leveldb.cpp:176] Opened db in 2.270387ms
I1104 03:37:55.524250 28363 leveldb.cpp:183] Compacted db in 662527ns
I1104 03:37:55.524276 28363 leveldb.cpp:198] Created db iterator in 4964ns
I1104 03:37:55.524284 28363 leveldb.cpp:204] Seeked to beginning of db in
702ns
I1104 03:37:55.524291 28363 leveldb.cpp:273] Iterated through 0 keys in the
db in 450ns
I1104 03:37:55.524333 28363 replica.cpp:741] Replica recovered with log
positions 0 - 0 with 1 holes and 0 unlearned
I1104 03:37:55.524852 28384 recover.cpp:437] Starting replica recovery
I1104 03:37:55.525188 28384 recover.cpp:463] Replica is in EMPTY status
I1104 03:37:55.526577 28378 replica.cpp:638] Replica in EMPTY status received
a broadcasted recover request
I1104 03:37:55.527135 28378 master.cpp:318] Master
20141104-033755-3176252227-49988-28363 (proserpina.apache.org) started on
67.195.81.189:49988
I1104 03:37:55.527180 28378 master.cpp:364] Master only allowing
authenticated frameworks to register
I1104 03:37:55.527191 28378 master.cpp:369] Master only allowing
authenticated slaves to register
I1104 03:37:55.527217 28378 credentials.hpp:36] Loading credentials for
authentication from
'/tmp/MasterTest_LaunchDuplicateOfferTest_XEBbvp/credentials'
I1104 03:37:55.527451 28378 master.cpp:408] Authorization enabled
I1104 03:37:55.528081 28384 master.cpp:126] No whitelist given. Advertising
offers for all slaves
I1104 03:37:55.528548 28383 recover.cpp:188] Received a recover response from
a replica in EMPTY status
I1104 03:37:55.528645 28388 hierarchical_allocator_process.hpp:299]
Initializing hierarchical allocator process with master :
master@67.195.81.189:49988
I1104 03:37:55.529233 28388 master.cpp:1258] The newly elected leader is
master@67.195.81.189:49988 with id 20141104-033755-3176252227-49988-28363
I1104 03:37:55.529266 28388 master.cpp:1271] Elected as the leading master!
I1104 03:37:55.529289 28388 master.cpp:1089] Recovering from registrar
I1104 03:37:55.529311 28385 recover.cpp:554] Updating replica status to
STARTING
I1104 03:37:55.529500 28384 registrar.cpp:313] Recovering registrar
I1104 03:37:55.530037 28383 leveldb.cpp:306] Persisting metadata (8 bytes) to
leveldb took 497965ns
I1104 03:37:55.530083 28383 replica.cpp:320] Persisted replica status to
STARTING
I1104 03:37:55.530335 28387 recover.cpp:463] Replica is in STARTING status
I1104 03:37:55.531343 28381 replica.cpp:638] Replica in STARTING status
received a broadcasted recover request
I1104 03:37:55.531739 28384 recover.cpp:188] Received a recover response from
a replica in STARTING status
I1104 03:37:55.532168 28379 recover.cpp:554] Updating replica status to VOTING
I1104 03:37:55.532572 28381 leveldb.cpp:306] Persisting metadata (8 bytes) to
leveldb took 293974ns
I1104 03:37:55.532594 28381 replica.cpp:320] Persisted replica status to
VOTING
I1104 03:37:55.532790 28390 recover.cpp:568] Successfully joined the Paxos
group
I1104 03:37:55.533107 28390 recover.cpp:452] Recover process terminated
I1104 03:37:55.533604 28382 log.cpp:656] Attempting to start the writer
I1104 03:37:55.534840 28381 replica.cpp:474] Replica received implicit
promise request with proposal 1
I1104 03:37:55.535188 28381 leveldb.cpp:306] Persisting metadata (8 bytes) to
leveldb took 321021ns
I1104 03:37:55.535212 28381 replica.cpp:342] Persisted promised to 1
I1104 03:37:55.535893 28378 coordinator.cpp:230] Coordinator attemping to
fill missing position
I1104 03:37:55.537318 28392 replica.cpp:375] Replica
[jira] [Commented] (MESOS-2050) InMemoryAuxProp plugin used by Authenticators results in SEGFAULT
[
https://issues.apache.org/jira/browse/MESOS-2050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14201625#comment-14201625
]
Adam B commented on MESOS-2050:
---
Not every authenticator will want to use [InMemory]AuxProp SASL plugin, and if
we ever allow a `configure --without-authentication` we won't want any sasl
code in the master. Better would be something like a static initializer on
CRAMMD5Authenticator. Some way for the authenticator to load the credentials
once, after reading the commandline params and before any authentication
happens.
InMemoryAuxProp plugin used by Authenticators results in SEGFAULT
-
Key: MESOS-2050
URL: https://issues.apache.org/jira/browse/MESOS-2050
Project: Mesos
Issue Type: Bug
Affects Versions: 0.21.0
Reporter: Vinod Kone
Observed this on ASF CI:
Basically, as part of the recent Auth refactor for modules, the loading of
secrets is being done once per Authenticator Process instead of once in the
Master. Since, InMemoryAuxProp plugin manipulates static variables (e.g,
'properties') it results in SEGFAULT when one Authenticator (e.g., for slave)
does load() while another Authenticator (e.g., for framework) does lookup(),
as both these methods manipulate static 'properties'.
{code}
[ RUN ] MasterTest.LaunchDuplicateOfferTest
Using temporary directory '/tmp/MasterTest_LaunchDuplicateOfferTest_XEBbvp'
I1104 03:37:55.523553 28363 leveldb.cpp:176] Opened db in 2.270387ms
I1104 03:37:55.524250 28363 leveldb.cpp:183] Compacted db in 662527ns
I1104 03:37:55.524276 28363 leveldb.cpp:198] Created db iterator in 4964ns
I1104 03:37:55.524284 28363 leveldb.cpp:204] Seeked to beginning of db in
702ns
I1104 03:37:55.524291 28363 leveldb.cpp:273] Iterated through 0 keys in the
db in 450ns
I1104 03:37:55.524333 28363 replica.cpp:741] Replica recovered with log
positions 0 - 0 with 1 holes and 0 unlearned
I1104 03:37:55.524852 28384 recover.cpp:437] Starting replica recovery
I1104 03:37:55.525188 28384 recover.cpp:463] Replica is in EMPTY status
I1104 03:37:55.526577 28378 replica.cpp:638] Replica in EMPTY status received
a broadcasted recover request
I1104 03:37:55.527135 28378 master.cpp:318] Master
20141104-033755-3176252227-49988-28363 (proserpina.apache.org) started on
67.195.81.189:49988
I1104 03:37:55.527180 28378 master.cpp:364] Master only allowing
authenticated frameworks to register
I1104 03:37:55.527191 28378 master.cpp:369] Master only allowing
authenticated slaves to register
I1104 03:37:55.527217 28378 credentials.hpp:36] Loading credentials for
authentication from
'/tmp/MasterTest_LaunchDuplicateOfferTest_XEBbvp/credentials'
I1104 03:37:55.527451 28378 master.cpp:408] Authorization enabled
I1104 03:37:55.528081 28384 master.cpp:126] No whitelist given. Advertising
offers for all slaves
I1104 03:37:55.528548 28383 recover.cpp:188] Received a recover response from
a replica in EMPTY status
I1104 03:37:55.528645 28388 hierarchical_allocator_process.hpp:299]
Initializing hierarchical allocator process with master :
master@67.195.81.189:49988
I1104 03:37:55.529233 28388 master.cpp:1258] The newly elected leader is
master@67.195.81.189:49988 with id 20141104-033755-3176252227-49988-28363
I1104 03:37:55.529266 28388 master.cpp:1271] Elected as the leading master!
I1104 03:37:55.529289 28388 master.cpp:1089] Recovering from registrar
I1104 03:37:55.529311 28385 recover.cpp:554] Updating replica status to
STARTING
I1104 03:37:55.529500 28384 registrar.cpp:313] Recovering registrar
I1104 03:37:55.530037 28383 leveldb.cpp:306] Persisting metadata (8 bytes) to
leveldb took 497965ns
I1104 03:37:55.530083 28383 replica.cpp:320] Persisted replica status to
STARTING
I1104 03:37:55.530335 28387 recover.cpp:463] Replica is in STARTING status
I1104 03:37:55.531343 28381 replica.cpp:638] Replica in STARTING status
received a broadcasted recover request
I1104 03:37:55.531739 28384 recover.cpp:188] Received a recover response from
a replica in STARTING status
I1104 03:37:55.532168 28379 recover.cpp:554] Updating replica status to VOTING
I1104 03:37:55.532572 28381 leveldb.cpp:306] Persisting metadata (8 bytes) to
leveldb took 293974ns
I1104 03:37:55.532594 28381 replica.cpp:320] Persisted replica status to
VOTING
I1104 03:37:55.532790 28390 recover.cpp:568] Successfully joined the Paxos
group
I1104 03:37:55.533107 28390 recover.cpp:452] Recover process terminated
I1104 03:37:55.533604 28382 log.cpp:656] Attempting to start the writer
I1104 03:37:55.534840 28381 replica.cpp:474] Replica received implicit
promise request with proposal 1
I1104 03:37:55.535188 28381 leveldb.cpp:306] Persisting metadata (8 bytes) to
leveldb took 321021ns
I1104 03:37:55.535212 28381
