In the presence of SERVER-9489 (which affects a wide range of MongoDB versions), the instructions to resize the oplog are fragile and can easily cause an out of disk space condition. This is because users expect the space from the old oplog to be reused, and so often plan for this when sizing the new oplog. If the new size of the capped collection is a large fraction of the disk volume size (ie. larger than the available free disk space), then the createCollection({capped:true, size: ...}) will fail.

I suggest that a more robust approach is to drop the entire local db, since this is safe to do (the other collections will be automatically re-created and re-populated when the mongod is brought back up in the replset) and avoids any space reuse problems from SERVER-9489. However, this does require more care around saving the final oplog entry into a separate, different, unused temporary database which is then later dropped before the member is returned to the replset.