Help Unidentified Wakelocks (System_Server, Time_Daemon, etc)

[batz281]

Good day folks,

Issue:
I've noticed System_Server and a few other items (below) severely draining the battery on my Galaxy S5 (3-4% per hour, when it's normally .75%/hour). In the past few weeks (*usually* worse when I'm at the office), the top Kernel Wakelocks and "Process" wake time (reported by BBS) have been:

1. Ipc00000016_Time_Daemon (which I can't find ANY info about, even when just Googling “time_daemon”)
2. WakelockManagerTimeout (likewise - no useful info, literally only SIX (6) results on Google).
3. System_Server (nothing concrete when Googling besides "try Wakelock Detector")
4. "IPC_###_Event0"/ “event0-###” every now and then, where ### is a Process ID. When I check the PID via Terminal (Cat /proc/*PID*/cmdline) the PID ends up belonging to "System_Server".
5. Numerous EventXX-### records, where XX is an event number and ### is a Process ID (usually the same PID tied to Event0 as noted above).
6. Numerous Kworkers

Question(s):

1. To make a Windows comparison, it looks like System_Server is "RunDLL32" or "SVCHost", wherein, numerous processes can "hook" into "System_Server" and are thus disguised behind that process name. Does anyone know if that is the case? Any sources to confirm?
   
   
2. Is there any way to dig deeper into "System_Server" to find the ACTUAL process/service/app/hardware that is causing all these wakelocks? I've also tried GSam Battery Monitor (thanks to - this post) and WLD (Wake Lock Detector) but the most specific any of them get is just "System_Server", even when I chase all the other Process IDs.
   
   
3. Does anyone have any idea what Time_Daemon does?

As far as I can tell, this did not start as of newly installed software, but it could certainly be due to an update to an existing program. Whatever the cause, though, I need to find out, because a dead phone is useless

 

[AZgl1500]

Not even close to an answer for you on "the what", but my method of controlling battery power is to simply turn off the internet when the screen is locked. I prefer to do it automatically with MacroDroid which my signature shows. I get pretty much 3 days per charge cycle for light to moderate use. 2 days when I'm surfing and reading a lot of national/world news.

I do not play any games, nor do I watch any videos. I have a desktop computer for that which has a 24" screen on it and a full size keyboard.


____________________________________
Verizon Galaxy S5, KK 4.4.4, ART
MyPhoneExplorer saves your tailbone
Nova Prime, Textra, Blue Mail, Qi wireless equipped
MacroDroid senses Screen off, turns Wifi & Data OFF
MacroDroid senses Screen on, turns WiFi & Data ON

 

[EarlyMon]

The system is servicing requests from other apps and services.

The time daemon keeps your clock set to network time, and will service time lookup requests. Something else besides the main clock could be asking for time, for example.

An IPC is an inter-process communication method - see my comments above about work being distributed.

Kworkers are just little kernel workers - processes and threads that are a red herring unless you know how to debug the entire system.

Let's look at a requirement - sync mail every two hours.

Unacceptable way - spinlock. Spin in a loop checking until the right time hits. Typically a cpu hog, definitely a battery killer.

Acceptable way - set a service to wake up mail in two hours and go to sleep until signaled. Simple example - the mail app sets up a non-existent network connection with a two hour timeout. The network chip handles this very efficiently on a pc.

Or build a general system for timed wakeups, including a watchdog that won't let a broken process force a permanent awake. On that, no system is idiot proof and some apps are idiots.

To see exactly which ones if you're rooted, use Wakelock Detector. Rather than just saying it's the system, it identifies what apps started what and how often.

Not rooted, try GSam Battery Monitor. It cannot give as much detail but if a service is showing the wakelocks, you can tap it and it will tell you what apps or services started it, often making process of elimination for the rogue process much easier.

In your case, you've tried both, I'm surprised that this isn't resolving better.

Are you running Dalvik or ART? If Dalvik, have you cleared cache and Dalvik yet?

 

[batz281]

AZGl1500, thank you for the tip about the MacroDroid.

EarlyMon, thank you for the detailed information (and confirming my suspicions about System_Server). Since they all seem to play nicely together, I've actually been running BBS, WLD, and GSam together, trying to correlate results from all of them when the serious battery drain occurs.

For example, looking at Kernel Wakelocks in WLD, in the previous 30 hours, IPC000000016_Time_Daemon ran for 41 minutes...that seems like an awful lot of network time syncing. Is this indicative of bad service (e.g. 1 out of 5 bars)? Right next to that is Event0-1366 (where 0 = zero) which ran for 50 minutes.

Checking CPU wakelocks in WLD in the same time window, AndroidSystem is the top with 26 minutes (#1 subsystem is TimaService which accounts for 10 minutes of the 26, then AlarmManager for 6 minutes, and WakelockManagerTimeout for 4 minutes). I found what Tima is here (http://tinyurl.com/l5rfmtf) but I don't know what a "normal" amount of waketime is for that service.

And comparing that with BBS, the Kernel Wakelocks are all identical (of course) - Event0-1366 and Time_Daemon. The Process list in BBS shows System_Server at the top with 28 minutes (of "Sys:") and 52 minutes (of "Us:"); I assume the difference being "system" and "user" timers. Could it be that Time_Daemon and Event0 are called by System_Server?

Up to now (researching because you asked) I had no idea the difference between ART and Dalvik (knew about and have been clearing Dalvik cache every so often, didn't know about ART as a runtime). But more to your question, the issue has persisted after clearing regular and Dalvik cache.

 

[EarlyMon]

Simple button - what is GSam telling you about your cell radio connectivity?

If it's the pits then everything flows from that, as the system tries to recover a reliable connection to the world.

 

[batz281]

After monitoring for a few days and comparing all the evidence, I *think* the culprit is a network extender at my office. Most of the day at my desk, my phone hovers around "Medium" (2) on the GSam Phone Radio gauge (when connected to the regular cell network). For some reason, in the past few weeks, I've noticed my phone connecting to a network extender, and that seems to coincide with the System_Server, Event0 and Time_Daemon events. I asked our Network Admin whether anything has changed with any of the extenders/repeaters, and will see what they say. Today, for example, I didn't notice any network extender activity at all, and battery drain was around .8%/hour.

That said...none of the battery monitoring utilities seem to track "Network Extender" time, and a quick Google didn't return any promising results. Any idea on how to track the time my phone spends connected to an Extender?

 

[EarlyMon]

Great sleuthing! And I think you're right.

As to your question -

Geniuses like me (said with tongue in cheek, even though I've professionally designed and developed *nix system programming and kernel mods (like a lot of guys ok)) and geniuses like the monitor app developers (no tongue in cheek) all seem to share an obvious, dirty secret -

We treat these things primarily microcomputers (Android is just a real-time, compact Linux) that also make phone calls.

In reality, they're phones that support microcomputers - the opposite of what we all know. And breaks the assumptions inherent in computer monitoring.

And *everything* in the design is to prioritize radio operations first - and one of the reasons that I love the GSam radio signal graph.

From "genius" (lol) to beginner, we all know the same thing - with fringe reception, radio (of ANY kind) getting, losing, getting, losing signal (and always looking for better) battery life drops like a rock.

I don't know of an app that will track what you want - it may exist but I haven't found it.

The telephony experts I know get the microcomputer side but not at the level we need to get the actual transactions explained.

The telephony experts I've met have worked for the manufacturers and even with NDAs haven't opened up to me - it's competitive info and I had no right to know.

I was hoping that we could track this to something wonky like a runaway calendar or Google Play Services install (I've had both).

But if you have evidence that it's radio related - and I think that you do - then there it is.

You can experiment by shutting down combinations of wifi and mobile data, see if it confirms your observations.

If so, then you have your answer - and it's an external factor that you might only mitigate, not control, by manipulating your radios - IF that's an option.

 

[batz281]

Appreciate all the insight, EarlyMon, and hey, self-title as a genius all you want - having worked on kernel mods puts you past me in the "development" department. My specialty is building (systems) and troubleshooting/debugging things.

The bummer is (and I guess this goes to the phone-with-microcomputer-attached model) not being able to discern with absolute certainty that the network extender is the cause (though the evidence is compelling). Even when on the N.E, the GSam radio monitor reports the same "percentage" of signal strength (e.g. "78% at Medium - 2").

I run my smartphones as pretty tight ships, so to speak, because in my mind, they need to be phones first, and smartphones second - it doesn't do me any good being able to GPS, Skype, and browse the web, if that killed the battery so I can't make a phone call . As such, I have Titanium Frozen / Greenified anything I know I don't need, and I keep the 4G / WiFi disabled (with no auto-enablers) and only enable them manually when I intend to use them. I have no syncing, no pushing, no pulling, no updating widgets, no Facebook, etc. With the final point being, short of an errant wakelock, I think most of my drain is from the cell radio haha.

I'll keep checking with our Network Admin about the N.E, and I suppose I could disable the cell radio via Airplane mode to further test it. Thank you for all the thorough explanations, EarlyMon!