I have a Nexus 4 running stock rom kit kat 4.4.2. There were few instances, in which when the phone goes to sleep, I see the notification light blinking indicating a new email/message, but it doesn't wake up when I press the power button. I have to soft reboot the phone {press the power button for 5 seconds to turn it off, then turn on}to use it again. This happens more frequently on some days, and some times it doesn't happen for weeks.I tried calling the phone from my land line when it is in this state, I could hear it ringing on the landline, but the phone doesn't actually ring. After rebooting, it doesn't even show a missed call. When I reboot it, the phone's battery is substantially less (down by about 10%). It started happening only since 4.3 JB update, it was fine till then.

I tried a full factory reset, and minimal apps, it worked fine. Once I installed all my apps back, this started happening again. I am thinking one of my apps is causing this and it could be an application or a bug in Kit kat/JB itself.


Is there any known bug in kitkat 4.4.2 (or >= 4.3 ) or is there any application known to cause this?
Is there any way I can look at the logs to see if any specific application is causing this.
Force wake up the phone without having to reboot it ?



Question: Is it possible to Cap a GridFS collection?
Answer: To make a long story short: you can not cap GridFS in a useful way. Here is why:

When you store a file in GridFS, it is split into chunks of 255kB, by default in a collection named fs.chunks, which absolutely can be capped by doing

db.createCollection("fs.chunks",{capped:true, size:52428800})


The capping would apply to those chunks, which are individual documents. So when you add a file which would make the fs.chunks to exceed its cap, only chunks of the oldest files would be removed. Another problem would be that the files metadata, which is stored in fs.files by default, would not be updated, leaving stale entries in fs.files for which no entries in fs.chunks are present any more, or – worse – only a fraction of the chunks are still present.

There are ways to overcome this (checking if the size in bytes of the chunks combined equals the length field of the fs.files document of the respective file, for example), but they are at least as complicated (and much slower!) as doing a check pre-insert wether the collection would exceed the threshold using the collections stats and delete as many of the oldest files as needed to fit the new file in without exceeding the threshold. 

The latter, by the way, is my suggestion on how to solve your problem.

Another solution would be to use a dedicated instance with the limitations applied in my answer to the question you mentioned.