Mongo 2.6.4 won't stepDown() because can't find a secondary within 10 seconds, but rs.status() shows optimeDates in sync - mongodb

Question

I'm attempting to step down my mongo primary and have my secondaries take over - mongo won't step down and says the my secondaries are more than 10 seconds out of sync. Yet my replica set says they are in sync - I'm baffled and it is likely something silly I'm missing
here's my output:
MongoDB shell version: 2.6.4
sessionV2:PRIMARY> rs.stepDown()
{
"closest" : NumberLong(0),
"difference" : NumberLong(1441842526),
"ok" : 0,
"errmsg" : "no secondaries within 10 seconds of my optime"
}
sessionV2:PRIMARY> rs.status()
{
"set" : "sessionV2",
"date" : ISODate("2015-09-09T23:48:53Z"),
"myState" : 1,
"members" : [
{
"_id" : 0,
"name" : "sessionv2-mongo-replset-moprd1-02:27017",
"health" : 1,
"state" : 1,
"stateStr" : "PRIMARY",
"uptime" : 2659,
"optime" : Timestamp(1441842533, 61),
"optimeDate" : ISODate("2015-09-09T23:48:53Z"),
"electionTime" : Timestamp(1441839881, 1),
"electionDate" : ISODate("2015-09-09T23:04:41Z"),
"self" : true
},
{
"_id" : 1,
"name" : "sessionv2-mongo-replset-moprd1-01:27017",
"health" : 1,
"state" : 2,
"stateStr" : "SECONDARY",
"uptime" : 2658,
"optime" : Timestamp(1441842531, 120),
"optimeDate" : ISODate("2015-09-09T23:48:51Z"),
"lastHeartbeat" : ISODate("2015-09-09T23:48:51Z"),
"lastHeartbeatRecv" : ISODate("2015-09-09T23:48:51Z"),
"pingMs" : 0,
"syncingTo" : "sessionv2-mongo-replset-moprd1-03:27017"
},
{
"_id" : 2,
"name" : "sessionv2-mongo-replset-moprd1-03:27017",
"health" : 1,
"state" : 2,
"stateStr" : "SECONDARY",
"uptime" : 2658,
"optime" : Timestamp(1441842531, 120),
"optimeDate" : ISODate("2015-09-09T23:48:51Z"),
"lastHeartbeat" : ISODate("2015-09-09T23:48:51Z"),
"lastHeartbeatRecv" : ISODate("2015-09-09T23:48:52Z"),
"pingMs" : 0,
"syncingTo" : "sessionv2-mongo-replset-moprd1-02:27017"
}
],
"ok" : 1
}
sessionV2:PRIMARY>
here's what the primary reports as far a status:
sessionV2:PRIMARY> rs.printSlaveReplicationInfo()
source: sessionv2-mongo-replset-moprd1-01:27017
syncedTo: Wed Sep 09 2015 19:15:02 GMT-0500 (CDT)
1 secs (0 hrs) behind the primary
source: sessionv2-mongo-replset-moprd1-03:27017
syncedTo: Wed Sep 09 2015 19:15:02 GMT-0500 (CDT)
1 secs (0 hrs) behind the primary
sessionV2:PRIMARY>
and an oplog view from a secondary:
sessionV2:SECONDARY> db.getReplicationInfo()
{
"logSizeMB" : 5120,
"usedMB" : 5077.25,
"timeDiff" : 12226,
"timeDiffHours" : 3.4,
"tFirst" : "Wed Sep 09 2015 15:53:29 GMT-0500 (CDT)",
"tLast" : "Wed Sep 09 2015 19:17:15 GMT-0500 (CDT)",
"now" : "Wed Sep 09 2015 19:17:15 GMT-0500 (CDT)"
}
thanks in advance!
2015 Sept 10th update:
we stopped each secondary and performed an initial sync from primary - then attempted to step down the primary again - it looks like the PRIMARY can't find the secondary oplogDate (we were unsure if forcing would free a SECONDARY to take PRIMARY)
sessionV2:PRIMARY> db.runCommand( { replSetStepDown: 60, force: false } )
{
"closest" : NumberLong(0),
"difference" : NumberLong(1441936029),
"ok" : 0,
"errmsg" : "no secondaries within 10 seconds of my optime"
}

Answer 1

issue solved! - I was playing with workarounds and documenting the replica setup - our initial scripts set the primary at default priority and the secondaries at priority 0 (which means they will never take PRIMARY role) - so basically -> bad config and the error message doesn't give any info onto the root problem (the docs are pretty clear, just missed it because I trusted our init scripts) - if you run into this and your replicaset oplogs are up to date, double check that the priorities are not set at 0