yashsingh1/xdaforums huggingface dataset:
[SuperSU] Chainfire:
(1) I'm not sure what I'm doing with this. Still looking/pondering. The options I have for this have different implications, especially for multi-user, I want to make sure I pick the right one. It's never going to be possible to be 100% identical to a non-daemon su. As such, root app devs will just have to learn to cope with the quirks and update their stuff.

(2) Don't you mean this the other way around ? On 4.2, mounting r/w would *not* show up for other processes, while it does with daemon-su. It is very loosely related to (1). This is also very delicate, as making the mount space private here has repercussions for repeated commands by the same process, while keeping it public allows apps to r/w or r/o while a different apps expects the other one to be current. A true shared private mount space between the calling app and the commands executed as root, will never again be the case.

You really need to let go of the "omg everything needs to work exactly the same" - it won't. 4.3 is a different beast, and it will not be 100% compatible root-wise. App devs will need to update. That being said, obviously trying to get as close as possible.
[SuperSU] 3c:
Thanks, I've already published an update this morning for my app to cope with this bug.
[SuperSU] nolig2278:
I was able to install super su.com the zip by owning with file explorer and selecting install. Will that be enough to protect root when I install the ota? I also used android root tool kit to protect root.

Thanks
[SuperSU] gamepois0n:
but will it interfere with superuser?

Signup and get 15 Gb free plus an extra 5 Gb each using this link: https://copy.com/?r=vOeT9D
[SuperSU] osm0sis:
I added the daemonsu service to init.rc where it would normally call install-recovery.sh:

service daemonsu /system/xbin/daemonsu -d
class main
user system
group system

So far so good on the franco.Kernel-tuna-r384 + stock JWR66V ramdisk hybrid I'm playing with. :good:

Could be a good option for ROM makers.

Edit: Trying "class core", and the extra property "critical" now. Nothing seems to entirely resolve the daemonsu CPU spike/slowdowns that I can tell. :(

Still a good solution for not using shell scripts though!
[SuperSU] franciscofranco:
That seems to be a good thing :)
[SuperSU] osm0sis:
If things start to get weird again we could also try throwing the "critical" property into the mix to see if that helps. :cowboy:

Edit: Or switching the class to "core" and/or user to "shell" or "root" :good:
[SuperSU] segv11:
ROM makers could also revert the change and allow us to run with full root privs...

Sent from my stock 4.2.2 mako.
[SuperSU] franciscofranco:
By the way [MENTION=631273]Chainfire[/MENTION] thanks for everything you do on the Root scene :)
[SuperSU] osm0sis:
Haha touché. :laugh:
[SuperSU] kingofcomedy:
After I have updated my Nexus 4 to 4.3 (via OTA-Zip) I installed the zip-file from the Google+-Posting through CWM and answered the question "disable stock recovery flash" with no, but now I don't have any recovery working (just an android with a red exclamation mark). Looks like I should flash a factory image and restart from scratch. :)

Edit: root isn't working too.
[SuperSU] Chainfire:
Try as I might, I can't get the high CPU load issue to occur. I need help finding this, and I need it quick, because I'm leaving on vacation.

If you can reproduce this issue, for starters, I need this:

adb shell top -n 1 > top.txt
adb shell ps > ps.txt

Zip up and post the top.txt and ps.txt files.

If you really want to get this solved, jump on to IRC and find me there, so we can debug this issue.
[SuperSU] osm0sis:
I would if I wasn't about to start a 12hr shift, so hopefully someone else can step up and help.
[SuperSU] efrant:
Attached.

I may have some time in a few hours to get onto irc.
[SuperSU] Chainfire:
Find me on IRC when you can. Don't really see anything weird from this, was hoping maybe it was a rogue su session gone bad, but that doesn't appear to be the case. Will need further investigation.

How quickly does the issue occur after booting? Because we will need to be doing some booting :)
[SuperSU] efrant:
It happens anywhere from a few minutes to a couple of hours after a reboot. I lose root and the daemonsu process starts eating up the cpu time.
[SuperSU] jesssiii:
This hasn't happened to me. Been up for 10 hours now. How do you notice it, when it does happen? I know I haven't lost root cause I've been using root apps the last hour and periodically opening supersu.

Galaxy Nexus Toro

Shiny ROM 4.3
[SuperSU] fireb33:
I manage to run forever without issue... but when I open CMFM and it obtains root access, and only AFTER I close the app, root is gone and daemonsu goes crazy... anyway elevated terminal sessions opened BEFORE closing the guilty app work just fine

I think it's related to certain apps, maybe starting at boot or after a certain amount of time... I have no root apps starting at boot and CPU load stays normal until user interaction
[SuperSU] franciscofranco:
I also cannot reproduce the high CPU usage reported by some users even after using my app running some SU commands every now and then everything seems normal to me. If anyone knows of any way to viably reproduce the issue I'll gladly try to help.
[SuperSU] fireb33:
the only app I know causing the issue is CM File Manager... try doing an operation when in root access mode, then close app and root should be gone

thanks!
[SuperSU] efrant:
I have Show CPU usage enabled in developer settings, so I can see when the daemonsu process starts eating up the CPU time.

I'm currently chatting with Chainfire. I was able to reproduce it, and sent him a logcat.
[SuperSU] Tungstwenty:
[MENTION=631273]Chainfire[/MENTION],

Just out of curiosity I took at look at some of the numbers and addresses from the 2 files.

Probably nothing you haven't seen but here it is anyway.

There are 3 /system/xbin/daemonsu processes:

193 - parent is /init

11985 - spawned by 193

11986 - spawned by 11985, and it's in the Zombie state

The one grabbing the CPU (40%) is 193.

At the moment that "ps" was executed it was at address (PC) 0x0000856c, which looking at your binary is syscall "accept". WCHAN is 0xffffffff, which I presume means that the snapshot was taken when it was still/already in user context, i.e. immediately after returning from the kernel code and resuming towards next call to read 4 bytes, etc. (I'm not sure about this, though)

There are 2 su processes (8597 from u0_a132 and 9005 from u0_a417).

Both of them were caught at PC 0x00008364, for the syscall "select", this time mapped to kernel address / WCHAN 0xc0130914 which is consistent between the several su/daemonsu processes on select, and also for other things like logcat, dhcpd, etc. also "paused" on select.

The fact that 193 is the one consuming CPU might indicate that it's continuously accepting new connections and spawning new processes/threads, which quickly die (and a hint is the zombie process), and these children don't show up on top since there are lots of them but short lived.

But the fact that accept was caught immediately before/after entering the kernel code (assuming my reasoning is right) could be misleading and be just an act of coincidence on this particular ps snapshot. Grabbing another one might be useful to see if it's stopped there once again (it would be odd, considering it's not in kernel space, blocked).

One other possibility - is it reasonable to consider that the fact that 2 different users (u0_a132 and u0_417) are both stuck on select, mean that it was some sort of race condition?

That would be my best guess, except for the fact that the master daemon is spinning and was snapshotted at accept() which is odd, since it's a blocking call...

Again, none of this affects me at all, I just got curious and it was fun checking the meaning of WCHAN and PC and seeing it makes sense when cross-checked against the binary :)
[SuperSU] fireb33:
good news!
[SuperSU] Chainfire:
Can you reliably reproduce this? i.e., reboot, use CMFM, cause issue, reboot use CMFM, cause issue, etc? It would be very valuable if you could!

Interesting investigation, but not leading anywhere, unfortunately. The main thread is indeed pretty much always hung up on accept, it's the background threads dealing with child communication that will cause the CPU spike. Don't worry about the zombie either, it'll be cleaned up when possible.
[SuperSU] fireb33:
I can reproduce it, it happens everytime. How could I help you?
[SuperSU] Chainfire:
Can you jump on IRC or Google Talk / Hangouts / some other form of IM ?

What firmware are you on? I can't seem to get CMFM working in anything else than safe mode ...
[SuperSU] fireb33:
I'm working now, I can join IRC at 20:30-21:00 CEST (I think we are in the same timezone)

I'm using my stock rooted odexed ROM http://xdaforums.com/showthread.php?t=2010887

CMFM works fine in root access mode until I close it
[SuperSU] Chainfire:
In the meantime, can you turn on "Full content logging" for CMFM, reboot, try again, and see if the problem persists ?
[SuperSU] GldRush98:
Not sure if relevant but thought I'd post it:

I have seen it once, when I first got SU working again. I had to go through and start all my root apps once to Allow them. All went off with out a hitch until I ran lagfix. Lagfix ran but then my phone started lagging. I moved on to my next root app in my list (TitaniumBU), but when I ran it, root was gone. All of my other root apps were also now reporting missing root (including SuperSU). I rebooted and have not seen the issue again... I have also not tried to run Lagfix again though.

edit: Decided to run lagfix again. Could not reproduce :(
[SuperSU] fireb33:
done, same problem

I have the log, I can upload a screenshot

EDIT: there are few screens, how can I extract logfile?
[SuperSU] Chainfire:
I've sent you a PM with a debug build for making extensive logs ... it would be great if you can produce the error and send me the logs.

Unfortunately that ROM is a Nexus 4 ROM, and I don't have a Nexus 4 ...
[SuperSU] polobunny:
Always had issues with CMFM on my Nexus S under 4.1.2/4.2. Simply froze it in TiBU and ditched it for something else and never looked back. Sometimes it would never acquire root for some obscure reason, and although I realize this has nothing to do 4.3 it might not be the best thing to base your observations on it.

2 cents.
[SuperSU] fireb33:
I will try as soon as possible

Do you have a Gnex? The issue appears on it too

http://xdaforums.com/showthread.php?t=1882248

---------- Post added at 05:17 PM ---------- Previous post was at 05:15 PM ----------

It's not about CMFM or another file manager, we are trying to reproduce the issue and isolate the problem. CMFM always worked fine for me and suddenly stopped with 4.3 causing the daemonsu issue

It can't be a coincidence..
[SuperSU] fanpengyuan:
Hi Chainfire

Firstly I have to say thank you for this great app :good:. I am a fan of your work and purchased a couple of apps and they work great.

I have a few questions with regarding to SuperSU when used with SuperBean 1.5 rom for Galaxy Note I. Understand that some of the questions are ROM related so please do not be offended if these are nothing to do with SuperSU.

1. I can install SuperSU via the market, and use as an non-system app. But if I install it to system then the icon will disappear all together. Q: Is it necessary to install it into system?

2. I tried to flash the zip file, despite it says flashed ok, it will lose root altogether. The stock Superuser cannot be used, nor is there SuperSU.

3. The ROM came with Superuser, and is showing as a menu item in system settings rather than an app. If I want to remove it from the Settings menu, is it possible? Or replace it with SuperSU will be good too.

4. Maybe a little warning to others using this rom, do not use TWRP/CWM method to install the binary as it will lose root altogether. I learned the truth the hard way.

Hope to get some answers. Thanks in advance.
[SuperSU] Chainfire:
Yup, downloading.
[SuperSU] Pkt_Lnt:
Pretty much all your questions have been answered in the last few weeks in the thread, I'd strongly suggest you read back at least 10 pages, maybe 20.
[SuperSU] nyt:
It seems Fauxclock app on n4 triggers the bug as well. If you need any debugging, will be happy to help.
[SuperSU] fireb33:
Chainfire identified the issue! Just tried a test version and it's working flawlessly, he's already working on a release

:D
[SuperSU] backslashV:
solution for android 4.3

Folks that are facing difficulty rooting their nexus 7, nexus 10 and galaxy s4 head over to this official post by chainfire to root their updated device. (Android 4.3)

https://plus.google.com/113517319477420052449/posts/9rcWNJbVZkL
[SuperSU] dzap:
I flashed stock over fastboot last night and have tried a variety of Root options from the one on Google+, to the various ROMs that have been pre-rooted.

Every single one, has brought my Nexus to an extreme stand still with lag, as I loose superuser permissions shortly after boot, and I receive the "SU binary is not installed" error, and many of the apps that I did grant root access to, did not recognize root permissions. Checking CPU utilization in developer options shows the sudaemon taking up a lot of my CPU (Can't verify 100%, but my battery life went from 60% to 14% in roughly an hour), and several su prompts appeared.

However, this worked!

Posted on AndroidPolice by another user for the Galaxy S4 for the JWR66V build.

http://www.androidfilehost.com/?fid=23050663588004537

Source thread : http://xdaforums.com/showthread.php?t=2369130

I'm not sure what is different about it, but it allowed all my apps to recognize root, my CPU utilization went down to normal, and my Nexus has stopped draining battery and lagging. I was literally about to go back to 4.2.2 but this fixed all my issues. I hope it helps someone else.
[SuperSU] ryaneu:
I did a compare and noticed that the size of superuser.apk in that zip file is different from the one in Chainfire google+
[SuperSU] lparcshinoda:
https://plus.google.com/+Chainfire/posts/9rcWNJbVZkL

That was an experimental root by Chainfire itselft that made it the Play Store some minutes ago.
[SuperSU] SypherNL:
Would it be possible to flash this with Flash Gordon?

My device is fully stock, not unlocked or anything. Previously I was using motochopper's root trick that allowed me to root my Nexus 7 without needing to unlock the bootloader (and thus losing all my data).

If it can be flashed with the Flash Gordon app it would save me once again. Anyone?

Edit: Hmm, selecting this file in Flash Gordon results in "The package you selected is not a valid flashable zip". Although the "Flash Now" button might be able to be clicked. But since I'm not sure what this will do (if there are any side-effects) I probably wait until someone can confirm this for me.

Edit 2: D'oh, that app requires root to begin with. :(
[SuperSU] lordlad:
The build number is also different...
[SuperSU] Erroneus:
Didn't do anything good for me, still not able to root my Nexus 4 with 4.3, and tried pretty much everything, but thanks dzap :)
[SuperSU] iowabeakster:
Ok, I'm getting a bit confused here.

The SuperSU-JWR66N-S005-130625-1.41.zip (the one linked to in the google+ post which is linked to in the OP, in red). That build still has problems with some apps, correct?

And chainfire does have another that does fix everything (not available for distribution yet). And all we need to do is simply wait patiently, correct ?
[SuperSU] fireb33:
You understood everything :D
[SuperSU] nyt:
1.43 released.

https://plus.google.com/113517319477420052449/posts/Jkuu84odnx6
[SuperSU] Chainfire:
v1.43 is now available in ZIP form. CF-Auto-Root's and Play Store update to follow.

https://plus.google.com/113517319477420052449/posts/Jkuu84odnx6
[SuperSU] fireb33:
Thank you Chainfire :good:
[SuperSU] rcs408:
Hello!

I'm still having all the same 4.3 issues with SuperSU-1.43 on my Nexus 7.

- Still get a "Could not remount /system" error when tryting to move apps with App Mover.

- Still cannot change my device's hostname with Change Hostname.

- DataSync still fails to carry out syncs as expected.

- On the bright side, TiBu appears to be working correctly -- I haven't changed the default folder.

Is this a SuperSU issue, or do the individual apps need updates to play nice with root in 4.3?
[SuperSU] jumperalex:
Soooo what was the problem? Or would it hurt our widdle heads! :)
[SuperSU] Chainfire:
Mostly 4.3 compatibility issues probably, no doubt the devs will update for 4.3 soon enough.

It's like this with every Android release ... just usually not as bad as this time. It's not unprecedented, though.
[SuperSU] 3c:
Thanks for the update.

So you "fixed" the SD path after all. How temporary is it, considering it works flawlessly? By the way, was this fix needed on the SGS4 (can't test it on the I9500 not having a 4.3 ROM yet).

IMO that was the best place to fix it, not that it bothers me as I've fixed it in my apps, but fixing 1 app is easier than fixing 1000+.

---------- Post added at 11:13 PM ---------- Previous post was at 10:53 PM ----------

Most of those issues relates to one thing: Google has increased security measures on many things, particularly on permissions only given to system apps and mount points being isolated.

Affected apps will have to be updated, and some features may no longer work: Such as Airplane mode switches, directory binders are 2 things that won't work in 4.3 (results may vary with devices actually), except if new tricks are to be found. There's probably more to be discovered. On the bright side, moving apps is not an issue, so you might want to contact App Mover's dev to check for an update.

Now, I'm wondeing, why use App Mover instead of TiBu to move apps? Doesn't TiBu allows moving apps?
[SuperSU] tarroyo:
Do you need to flash super su 1.43 every time u install another rom, or just once?
[SuperSU] 3rdstring:
After every ROM flash
[SuperSU] cmstlist:
GNex 4.3, now using the just-posted SuperSU 1.43.

I seem to be having a totally different Titanium Backup problem. I get a toast telling me that SuperSU did grant Titanium root privileges. But TiBu throws up the error "Sorry, I could not acquire root provileges. This application will *not* work! Please verify that your ROM is rooted, and try again. This attempt was made using the "/system/xbin/su" command."

Other apps such as Root Explorer and SQLite Editor do not seem to have a similar problem - root access works just fine.

EDIT: Nevermind solved it. On SuperSU 1.41 I had tried to update Busybox using the Play Store app and it failed. On SuperSu 1.43 it succeeds, and after Busybox is installed I no longer get a startup error on TiBu.
[SuperSU] osm0sis:
Every time since /system will be getting wiped. That's the way it always was though unless your ROM already incorporated it. ;)

Sometimes you just need to make sure you've completely closed out the app too. TiBU in particular if it's failed to acquire root, you need to Back button out, then swipe it away from Recents to make sure it'll properly try to acquire root again. :)
[SuperSU] cmstlist:
Yeah I tried that many times. On SuperSu 1.41 I actually got a screenshot where you can see both the "TiBu got root" toast *and* the TiBu error message complaining it didn't:

But yeah the key appears to be: Upgrade to SuperSu 1.43, install Busybox from the Play Store app, and then try again.
[SuperSU] Chainfire:
That's because su actually works, but the system didn't grant root priviliges - it's an unchecked error that gives that weird combo.
[SuperSU] MarcSinger:
I just rooted using 1.43. I noticed my CPU load's constantly fluctuating between 0 and 50%, though it's mostly in the higher end of that range. Is this normal for Android?
[SuperSU] occtec:
Hi all, what is the best method to root? Does super su v1.43 include root or do I need to use cf-auto root first if so how do you flash cf-auto root is it via odin like on the galaxies?? Noob question I know, first time nexus user, sorry.
[SuperSU] 3c:
Hi Chainfire and much thanks for the 1.43 update, works very well. Not sure why my previous post was completely ignored, however I had a question for you:

You mentioned the SD path fix is temporary. How temporary will it be? Just to know if I can get rid of the in-app fix for this or not. Thanks.

---------- Post added at 12:26 AM ---------- Previous post was at 12:24 AM ----------

Flash 1.43 via CWM/TWRP, that worked for most (isn't that mentioned all over this thread?).
[SuperSU] occtec:
Point taken BUT, does this include root or

Is it just my misunderstanding?
[SuperSU] osm0sis:
It IS root. ;)
[SuperSU] 3c:
Yes it includes root, sorry missed that part. If you actually open the ZIP, you'll see /system/app/superSU.apk and /system/xbin/su ;)
[SuperSU] osm0sis:
For kernel devs that include their own ramdisks, here's the mod to make that I've settled on in order to natively support the new daemonsu:

/init.rc (line ~504 in stock GN kernel):

Change:

service flash_recovery /system/etc/install-recovery.sh
class main
oneshot

To:

service daemonsu /system/xbin/daemonsu --auto-daemon
class core
user root
group root

This puts it with all the other core daemons running, and I figured our root daemon should probably have user:group root:root. :p

It also probably doesn't hurt to make it a critical process, probably a little more bulletproof that way.

Edit: Chainfire has pointed out that not all will want to remove the install-recovery.sh call, in that case make sure the new daemonsu service is above the flash_recovery service so that the native daemonsu service will be the one that's running in the case both exist. :good:

Edit 2: Removed the critical flag from the service to avoid possible bootloops into recovery when the service has to restart.
[SuperSU] Chainfire:
I think you should *add* that daemonsu service, and remove the install-recovery.sh file, while keeping the flash_recovery service. But that's just me.
[SuperSU] osm0sis:
Plenty of kernel devs just straight-up comment it out to prevent custom recovery tampering, but to each their own. :cowboy:

Edit: Also my way ensures we don't get two daemonsu's running (one from the native service and one from the install-recovery.sh your zip installed). :good:
[SuperSU] rdoane:
Chainfire, first and foremost thanks for your hard work. Quick question for anyone, if you flashed 1.43 will the app still update through the play store? Thanks in advance everyone.
[SuperSU] cmstlist:
When the Play Store version advances to higher than 1.43 it should show as an update to a system app.
[SuperSU] occtec:
Hey guys can anyone please share a link to the latest CWM recovery .zip that works with super su

Cheers:thumbup:
[SuperSU] Chainfire:
install-recovery.sh is pretty standard, commenting it out is just ... bad.

As for two daemonsu's, that can't happen. The second one run will detect the first and bail.
[SuperSU] osm0sis:
Perfect! Figured you might have done something like that, but I wasn't taking any chances. :)

Amended my post.
[SuperSU] occtec:
guys is it necessary to unlock bootloader on stock ROM before i flash recovery and root with super su? or is this only necessary for custom ROM
[SuperSU] shanedd1123:
http://teamw.in/project/twrp2

HTC One GE Convered 2.14.1700.15
[SuperSU] kartikb:
Is the latest version of SuperSU v1.43? I just updated mine from google play store and I am on v1.44. :confused:
[SuperSU] occtec:
Hi guys the answer is yes!

What is Bootloader and Why do we need to Unlock?

A bootloader is a boot initializing component which is generally locked by the device manufacturer to avoid any messing around with the OS. We need to unlock it for the same reason. Once unlocked it will allow us to change the boot sequence and modify the OS in accordance of our needs.

Thanks anyways, found my answer
[SuperSU] manbat:
=================

Me also....is their a flashable v1.44?
[SuperSU] DJxSpeedy:
i wanna know that too ;)

or can we simple replace the old apk with the new in the zip ? :D
[SuperSU] Leion:
I got a "failed" error message when i tried to flash the 1.43 zip file with twrp 2.6..

Anyone can tell me whats wrong?