NOTE:
If you came here looking to fix recent problems with LoS in recent builds of Jelly Bean, be aware that this utility has not been tested with JB or ICS at this time. I figured LoS was a solved problem, so retired the project. I'm looking into it again, and may have something out later depending on how much has changed in the OS updates.
Introduction
Has your phone ever had a circle with a line through it instead of signal bars? Has your phone ever shown signal bars, but all calls and texts fail until you reboot? Well, those situations are called Loss of Service, or LoS, and while we can't actually stop them from happening yet, those situations can be detected and repaired. The Loss of Service Daemon (LoSD) does that, so you don't have to!
It does this by:
Restarting problematic radio daemons when detected.
Rebooting when all attempts to fix have failed.
In addition, it can create a log dump of various system logs for debugging purposes.
Requirements
Phone must be rooted.
An init.d compatible kernel.
Busybox must be installed.
Many ROMs and custom kernels do this automatically, but check the feature of your basic tool-chain before installing.
Installation
All files are located in my github projuct, if you'd like to get a closer look at how all LoSD works. But what you really want to to know:
Download LoSD
This will be a file you can flash using ClockWorkMod. Simply copy it to your internal or external SD card, reboot into recovery, and flash. The next reboot will be running LoSD.
NOTE : Installing LoSD will automatically remove -viperboy-'s LoSChecker, as they should not both run at the same time.
Download LoSD Uninstall
The above package will fully remove all traces of LoSD from your phone. Flash if you're having problems or no longer need/want LoSD.
WARNING! Do not wipe anything before or after install of this utility! It is not a ROM. You will be left with an unbootable system.
Usage
If you installed the flashable zip, your phone will automatically launch the LoS daemon at every boot.
Or you can call it manually to obtain debugging logs!
Code:
LoSD dump
When called with the 'dump' command, LoSD will dump all debugging logs and exit, creating a timestamped directory in LOGPATH (/data/local/LoSD by default), as well as a tar archive named logs.tar.gz. This lets you capture situations where LoSD did not detect a LoS, and send the logs for analysis.
Frequently Asked Questions
These are taken from the README file that gets installed with LoSD. There's more dev-related info in that file, so give it a look!
Q: Will this restart the radio or the phone if I lose 4G?
No. 4G is actually a separate radio from the CDMA radio used for texts and phone calls. This script ignores the 4G radio entirely and can not trigger no matter what happens to the 4G radio.
Q: Will this restart the radio or the phone if I'm using WiFi?
No. Turning on WiFi *will* disable your 3G data, but will leave the CDMA radio in an available state so you can still receive phone calls and texts. The LoS daemon knows the difference, so feel free to use your WiFi as you please. LoSD may restart your radio while you're on WiFi, but only because your CDMA radio stopped responding and you wouldn't have received any texts or phone calls if it didn't try and fix the radio.
Q: Where do I find the logs?
Logs produced when the radio is restarted, or the phone is rebooted, are stored by default in /data/local/LoSD in a directory time and date stamped for when the fix was attempted, or a reboot was triggered.
Q: Help! My log directory is getting huge!
By default, LoSD will not dump system logs when it repairs a LoS. But you may have enabled it on your own if you modified the configuration file. If you're in a spotty coverage area, the log directory may start to fill with several timestamped log dumps, each of which are around 5MB. If you'd like to stop this, please ensure your LoSD.ini configuration file does not contain the following line:
Code:
DUMPLOGS=1
Such a line will enable log dumping, which again, is disabled by default!
Q: I think I have LoS the daemon didn't detect. How do I get logs?
Very easily! LoSD has a built-in logging command! Just type this into a terminal, or an 'adb shell':
Code:
su
LoSD dump
This will create a timestamped directory just like LoSD had detected it. In addition, a file named logs.tar.gz will be dropped in your LOGPATH directory (that's /data/local/LoSD by default) you can send to us. We recommend putting it in dropbox, or some other binary-file hosting site.
Credits
Many thanks to -viperboy- for the original concept of checking for LoS with a script.
HaiKaiDo gave us the idea of restarting the radio daemon before rebooting.
If I'm forgetting anyone, please PM me!
Configuration
There are several settings you can apply to the LoS daemon while it's working. These settings should be placed in a file named LoSD.ini in the /data/local/LoSD directory of your phone. If you change any settings, you must either restart the daemon, or reboot your phone.
Currently recognized settings:
DEBUG
Many log entries are only informative in nature and can be very noisy. If you are having trouble and want to see LoSD activity reported in the system logs and LoSD.log, set this to 1. Default is 0.
DUMPLOGS
Whether or not logs should be dumped during a LoS repair or system reboot. Should be 0 for false, or 1 for true. Default is curently 0.
LOGPATH
Full path to where logs should be dumped. This is also where LoSD keeps its own LoSD.log file. Default is /data/local/LoSD because the daemon knows that directory exists. Feel free to place it somewhere on your SD card. If this directory does not exist, LoSD will attempt to create it for you. Please make sure the path is writable!
RESTARTS
How may times should the daemon attempt to restart the radio before giving up and initiating a system reboot. Default is 2. This setting was primarily defined because ghost LoS can sometimes degrade into full LoS, and subsequent radio restarts may be necessary to regain service.
RESTART_LIMIT
How many successful radio restarts before LoSD considers the phone state tainted? Too many RILD restarts may damage other services, or cause other unknown side effects. After this limit is reached, further LoS events will not result in an RILD restart, but a full reboot. Default is 3.
SLEEP
How long to wait between radio checks, in seconds. Default is two minutes.
Example:
Code:
LOGPATH=/sdcard/los
RESTART_LIMIT=1
Again, if these settings are changed, you must either restart the LoS daemon, or restart the phone. To restart the daemon, execute the following in an ADB shell or terminal:
Code:
su
killall LoSD
nohup LoSD &
The 'nohup' is there to prevent the command from attaching to your TTY, so you can disconnect without your session hanging. Feel free to omit this if you were just going to close your TTY.
Change Log
Version 1.3.1
Added third Airplane mode check for ICS firmwares.
Third firmware check also works on phones with disabled logcat.
Version 1.3.0
Improved CDMA connection FAILED detection.
Added second Airplane mode check for EL13, EL26, EL29 firmwares.
Version 1.2.0
Added debug log level.
Moved several informative messages to debugging only.
Debugging is now disabled by default.
Tweaked RILJ error detection for RIL_REQUEST_CDMA_GET_SYSTEMPROPERTIES.
Can now ignore false positive ghost LoS caused by phone calls.
Phone call and Airplane mode now checked before anything else.
CONNECTING status no longer skips LoS check.
Added ghost LoS check for CDMA 'Unknown data error' messages.
Version 1.0.0
Log dumping is now disabled by default.
Now uses 'setprop ctl.stop/ctl.start' to try restarting RILD nicely.
Does a quick check to prevent multiple running copies.
Added a radio restart limit to avoid glitchy post-fix systems.
Clear radio log in case of false positive ghost LoS.
Version 0.9.0
Added non-LoS check for transient CONNECTING status.
Now check for ghost LoS *after* standard LoS.
Calling LoSD with 'dump' now dumps and tarballs all debugging logs.
Version 0.8.1
Fixed bug in grabbing bugreport dump.
Now removes -viperboy-'s LoSChecker on install.
Removed LoSD logcat dump in favor of persistent LoSD.log.
Version 0.8.0
Now maintains a separate log for tracking all LoS events.
Added DEBUG configuration setting.
Version 0.7.1
Fixed typo in AirplaneMode check. Should no longer reboot in airplane mode.
Version 0.7.0
Fixed bug in radio log dump.
Now tries multiple times to restart RILD before reboot.
Added DUMPLOG as boolean to disable / enable log dumps
Added RESTARTS as number of RILD restart attempts before reboot.
SLEEP, LOGPATH, DUMPLOG, and RESTARTS are now user configurable.
Now searches for /data/local/LoSD/LoSD.ini for config settings.
Version 0.6.0
Initial public release
Good deal, the more people working on this the better and I know viperboy had a lot of work going. I'll give your version a go today.
Sent from my SPH-D710 using xda premium
Just_s said:
Good deal, the more people working on this the better and I know viperboy had a lot of work going. I'll give your version a go today.
Click to expand...
Click to collapse
Haha. Thanks. The way I see it, Viper has his hands full with way more important projects right now. With his ROM, the EK02 pull, the ICS work... why should he have to worry about this too? He was going to rewrite his script anyway, so I just took the opportunity to do it while he was distracted being useful.
While I was at it, I just... added a few things. That's all.
installing now.. thanks for this, and thanks viper
How about an option that appends to a file a date and time that the los happened instead of the full log? How about a notification after it fixed a los? The viper script made the phone appear like I never have los. Good but I still would like to know how often it happens.
gedster314 said:
How about an option that appends to a file a date and time that the los happened instead of the full log? How about a notification after it fixed a los? The viper script made the phone appear like I never have los. Good but I still would like to know how often it happens.
Click to expand...
Click to collapse
I can do the feature to keep a running tally of LoS, but so far as I can tell, there's no way to send notices from the command line. If there is, I can't find it. Sorry.
Sent from my SPH-D710 using xda premium
Question... Do I need to be uninstalling this script everytime I update, or just flash over the old? -Grand
Sent from my SPH-D710 using XDA App
grandmastem said:
Question... Do I need to be uninstalling this script everytime I update, or just flash over the old? -Grand
Click to expand...
Click to collapse
Just flash it over the old one. I've made the install smart enough to install over previous versions of LoSD. If you're running -viperboy-'s LoSChecker, you should run his uninstall first, though.
Also:
Edited OP to reflect new 0.8.0 version. Added a setting to suppress the Info-level log messages. Now it also keeps a LoSD.log in the LOGPATH directory so you can keep a log of its activity between reboots without having the log dumping enabled.
I also updated the Configuration and Change Log sections.
After u install it wat u do to run it or do it run on its own
Sent from my SPH-D710 using xda premium
pats4life100 said:
After u install it wat u do to run it or do it run on its own
Sent from my SPH-D710 using xda premium
Click to expand...
Click to collapse
It runs on its own.
Is this JarJar Binks?
Sent from my SPH-D710 using xda premium
Just_s said:
It runs on its own.
Is this JarJar Binks?
Sent from my SPH-D710 using xda premium
Click to expand...
Click to collapse
+1 sir.....+1.......
Also thanks for the shoutout trifthen! Nice work
Giving this a go. I'll report in with anything that seems odd. I definitely get LoS on occasion, and the girlfriend doesn't approve haha.
trifthen said:
I can do the feature to keep a running tally of LoS, but so far as I can tell, there's no way to send notices from the command line. If there is, I can't find it. Sorry.
Sent from my SPH-D710 using xda premium
Click to expand...
Click to collapse
Trifthen, I'm glad you took this over cause I had alot of other stuff going on. If I see any enhancments, I will send them your way. Also, you have my permission to include the line in your updater-script to remove my LoSChecker because I don't want it to affect users who use yours and don't uninstall mine. Just add this into your updater-script:
Code:
delete("/system/bin/LoSChecker");
And you can also add a line to remove my logs as well if you want. The files might be taking up a good bit of space...
Code:
delete_recursive("/data/local/LoS");
Those should be right, I'm at work so I'm typing from memory
For counting when LoS happens, you could just write a timestamp or something else into a file (>> adds into a file, > overwrites any data in a file) and then just do a wc on it (-l option reads lines, I think) which would give you the number of times that you had LoS from reading the amount of lines in the file. Just a thought.
Yay no more this ****
Sent from my SPH-D710 using xda premium
-viperboy- said:
Trifthen, I'm glad you took this over cause I had alot of other stuff going on. If I see any enhancments, I will send them your way. Also, you have my permission to include the line in your updater-script to remove my LoSChecker because I don't want it to affect users who use yours and don't uninstall mine. Just add this into your updater-script:
Code:
delete("/system/bin/LoSChecker");
Code:
delete_recursive("/data/local/LoS");
Click to expand...
Click to collapse
Thanks man. I'll do that. I'll be waiting in anticipation for those enhancements. I actually just got a reboot following a ghost LoS where I couldn't send any texts. It couldn't restart the radio, and boom. The best enhancement we could get is to have no need for this utility. Heh.
... and then just do a wc on it (-l option reads lines, I think) which would give you the number of times that you had LoS from reading the amount of lines in the file. Just a thought.
Click to expand...
Click to collapse
Yep. The new /data/local/LoSD/LoSD.log is basically everything it sends to the system log, so it's like a mirror that persists after reboots, unlike the system logs. In addition, you can turn off those pesky "Radio appears normal - no LoS." information messages by setting DEBUG=0 in the config file.
I just found a cut-n-paste bug in the line that dumps the bugreport, so I may just add the lines that remove LoSChecker along with that fix.
Thanks again, Viper!
Is anyone else running a hacked PRL and running into issues like I am?
EDIT: Rebooted manually, held up at splash screen, weird series of beeps and now back up....running Blazer v.12 on EG31.
DizDroid said:
Is anyone else running a hacked PRL and running into issues like I am?
Click to expand...
Click to collapse
Well, if your hacked PRL is the 000000 one that puts you permanently on Verizon, that might be an issue. I noticed the phone killed my radio about 6 times today around the same 20-minute period while I was right on the edge of Sprint service and kept roaming on and off. I was standing in line for lunch in a building that's not nearly as tall or as deep as where I work, yet it was driving my radio nuts. LoSD's ghost LoS checks triggered multiple times, so I have plenty of logs to work with now so I can revise the check to be a little less overzealous.
I can't say for sure, but forcing yourself to roam may have a similar effect. Take it with a grain of salt.
trifthen said:
Well, if your hacked PRL is the 000000 one that puts you permanently on Verizon, that might be an issue. I noticed the phone killed my radio about 6 times today around the same 20-minute period while I was right on the edge of Sprint service and kept roaming on and off. I was standing in line for lunch in a building that's not nearly as tall or as deep as where I work, yet it was driving my radio nuts. LoSD's ghost LoS checks triggered multiple times, so I have plenty of logs to work with now so I can revise the check to be a little less overzealous.
I can't say for sure, but forcing yourself to roam may have a similar effect. Take it with a grain of salt.
Click to expand...
Click to collapse
Thanks for the reply, keep up the great work. If I wasn't trying so hard to get out of my Sprint contract I'd ditch the .000000000000000000000000000 in a heartbeat.
I did a basic search of the GNex section of the forum and didn't find any conspicuous information, thus I wanted to see if anyone had any suggestions for dealing with the "debuggerd" system process.
I have a yakjuux 4.0.4ota with franco-kernel milestone3. I started with 4.0.1 and no mods, upgrading to the 4.0.x otas as they came out. I have had this phone about 4-5 months now. I have been rooted and unlocked since I have had 4.0.1.
Not exclusively to the 4.0.4 nor the franco-kernel I have noticed a process "debuggerd" running on my phone. rcently, twice in a day I found that process consuming 30+% of the cpu, causing a sudden drain in my battery. Prior to 4.0.4 I had not gathered any empirical data as to how much debuggerd was consuming, but did have times when the battery would radically drain, and I did notice debuggerd running.
I was able to launch a shell on my phone and kill the process-id for debuggerd at which point cpu load would drop instantly.
I tried freezing (via Titanium) many of my apps that would use data or were running at the time of the high cpu load (I wasn't sure if that would free up what triggered the process, just thought it was worth a try). I turned off a lot of software (eg. tasker, alarmapps, etc). As I froze/disabled apps en masse it was still using up the cpu. I tried killing apps from within watchdog. Still debuggerd would maintain a high cpu load. A reboot did get rid of it once, but in that session it did come back. Played with the USB debugging mode. I didn't reboot between many of these test.
I'll continue to kill it's pid if it shows, which the signs are really obvious in watchdog app (set my system warning low enough to catch it). I'm just familiar with the problem now.
* Any suggestions on tracing what's triggering debuggerd?
* Thoughts on alternative methods to prevent it from being used?
* I doubt deleting that bit of software is a good idea, right?
* Substitute it with something inert?
* Maybe I should create a button that gets it's pid and kills it?
Thoughts?
I found a shell script on http://en.androidwiki.com/wiki/Android_Shell_tips_and_tricks
It finds the pid by name - which is handy since pid's can be random.
I can run the shell script with SManager (which can provide the shell script any required arguments) from the phone desktop without having to go into the console.
It's a bandaid but it works. I can quickly and easily kill the (or any) errant processes that are not apps.
#!/system/bin/sh
# usage: kill "/full/command/line -with arguments"
for file in /proc/[0-9]* ; do
cmd=$(cat $file/cmdline)
iseq=${cmd%$1}
if ! ( (echo ${cmd:?}) > /dev/null 2>&1) ; then
continue
fi
if ! ( (echo ${iseq:?}) > /dev/null 2>&1 ) ; then
kill -9 ${file#/proc/}
fi
done
I share the same problem. debuggerd is cpu hog.
I dont want to kill it as it is not normal in my case. It has been lasting for more than an hour with high cpu usage.
I am using franco kernel 158 and Samsung GNexus ROM 4.0.4 IMM76K.
any help would be appreciated. Thanks.
mcdull said:
I share the same problem. debuggerd is cpu hog.
I dont want to kill it as it is not normal in my case. It has been lasting for more than an hour with high cpu usage.
I am using franco kernel 158 and Samsung GNexus ROM 4.0.4 IMM76K.
any help would be appreciated. Thanks.
Click to expand...
Click to collapse
McDull,
I'm not sure what you mean by you don't want to kill it. Regardless, you could kill the process (not via any task manager, since dubuggerd isn't an app to force-stop). If you do want to stop it you could manually one of a couple ways.
On the phone by hand:
I'm assuming you have root and su access.
From google-play download:
--- "Top" (by Junichi Uekawa).
--- "Android Terminal Emulator" by Jack Palevich.
Use Top to find out what the process id# for debuggerd is.
Open Terminal Emulator:
--- I can't remember if you need "su" powers, I always enter "su" mode tho.
--- Execute a kill of the pid: kill xxxxxx
Switch to Top, see if the debuggerd resets itself. Kill again if necessary
You can do all of the above via adb shell from your computer too.
Somewhat more automated:
From google-play download "SManager" (script manager) by devwom.
Write a shell kill script like in my first post.
Using smanager you can create a desktop icon that executes the kill command.
(I'm glossing over the details a lot because I'm at work and didn't have time to write in depth smanager instructions to do this. sorry!!)
Hi,
I recently gave my KF to my little nephew to play games with, he took a little break and after returning to the tablet found my screen pattern to be a game as well. Anyways, it now tells me "too many wrong pattern" attempts and prompts me to log in with my google id. Unfortunately this does not work as it always gives me "invalid user id or password" very fast. I had wifi turned off so I cant imagine it would be able to log in to google and i doubt my password is stored locally. I read somewhere that this is a known bug.
Im running CM9 on it and am able to access it through adb. I found one solution which I tried and did not work, it goes:
Code:
> adb -d shell
# sqlite3 data/data/com.android.providers.settings/databases/settings.db
sqlite> update system set value=0 where name='lock_pattern_autolock';
sqlite> .exit
# exit
I also found an extended version of this, the exact syntax i dont remember but it was more for my case (something like 'locked_out_permanently'), I set the value to 0 as well, but no desired result. Of course the posts were from 2009 so for quite a few versions of android back. My CM9 is 4.04.
I have also found that there is an app called Screen Lock Bypass, which i imagine I would be able to install through 'adb install', but I have not found the apk.
Any ideas? I'd appreciate all help.
Would reflashing the rom work, you wouldn't lose any data or apps?
Sent from my Galaxy Nexus using XDA Premium HD app