'dumpsys netstats' processes pile up until Shizuku hangs

[daniele-athome]

I'm on the latest release of both Better-Internet-Tiles and Shizuku, running Android 15 on a Google Pixel 8.

I've been experiencing a bug that periodically (few minutes) makes BIT and Shizuku to both stop working. I've done some debugging, and I'm still not sure whether it's a Shizuku bug or a bad use of Shizuku API by BIT.

After a while, I see:

shiba:/ $ ps -ef |grep dumpsys                                                                                                                           
shell        21257 20510 0 23:52:14 ?     00:00:00 dumpsys netstats | grep -E 'iface=wlan.*(networkId|wifiNetworkKey)'
shell        21258 20510 1 23:52:14 ?     00:00:00 dumpsys netstats | grep -E 'iface=wlan.*(networkId|wifiNetworkKey)'
shell        21261 20510 1 23:52:14 ?     00:00:00 dumpsys netstats | grep -E 'iface=wlan.*(networkId|wifiNetworkKey)'
shell        21272 20510 0 23:52:14 ?     00:00:00 dumpsys netstats | grep -E 'iface=wlan.*(networkId|wifiNetworkKey)'
shell        21277 20510 0 23:52:14 ?     00:00:00 dumpsys netstats | grep -E 'iface=wlan.*(networkId|wifiNetworkKey)'
shell        21279 20510 0 23:52:14 ?     00:00:00 dumpsys netstats | grep -E 'iface=wlan.*(networkId|wifiNetworkKey)'
shell        21280 20510 0 23:52:14 ?     00:00:00 dumpsys netstats | grep -E 'iface=wlan.*(networkId|wifiNetworkKey)'
shell        21281 20510 0 23:52:14 ?     00:00:00 dumpsys netstats | grep -E 'iface=wlan.*(networkId|wifiNetworkKey)'
shell        21282 20510 0 23:52:14 ?     00:00:00 dumpsys netstats | grep -E 'iface=wlan.*(networkId|wifiNetworkKey)'
shell        21283 20510 0 23:52:14 ?     00:00:00 dumpsys netstats | grep -E 'iface=wlan.*(networkId|wifiNetworkKey)'
shell        21284 20510 1 23:52:14 ?     00:00:00 dumpsys netstats | grep -E 'iface=wlan.*(networkId|wifiNetworkKey)'
shell        21287 20510 0 23:52:14 ?     00:00:00 dumpsys netstats | grep -E 'iface=wlan.*(networkId|wifiNetworkKey)'
shell        21288 20510 0 23:52:14 ?     00:00:00 dumpsys netstats | grep -E 'iface=wlan.*(networkId|wifiNetworkKey)'
shell        21294 20510 0 23:52:14 ?     00:00:00 dumpsys netstats | grep -E 'iface=wlan.*(networkId|wifiNetworkKey)'
shell        21296 20510 0 23:52:14 ?     00:00:00 dumpsys netstats | grep -E 'iface=wlan.*(networkId|wifiNetworkKey)'
shell        21298 20510 0 23:52:14 ?     00:00:00 dumpsys netstats | grep -E 'iface=wlan.*(networkId|wifiNetworkKey)'
shell        21300 20510 1 23:52:14 ?     00:00:00 dumpsys netstats | grep -E 'iface=wlan.*(networkId|wifiNetworkKey)'

Those processes pile up until Shizuku stops working - goes ANR (BIT soon follows), killing and restarting it shows "Shizuku not running". If I issue killall dumpsys, Shizuku immediately resumes (goes out of ANR or transitions to "Shizuku is running") and the tiles work again - and the cicle starts again.

I can see this from Shizuku API newProcess:

/**
 * Start a new process at remote service, parameters are passed to {@link Runtime#exec(String, String[], java.io.File)}.
 * <br>From version 11, like "su", the process will be killed when the caller process is dead. If you have complicated
 * requirements, use {@link Shizuku#bindUserService(UserServiceArgs, ServiceConnection)}.
 * <p>
 * Note, you may need to read/write streams from RemoteProcess in different threads.
 * </p>
 *
 * @return RemoteProcess holds the binder of remote process
 * @deprecated This method should only be used when you are transitioning from "su".
 * Use {@link Shizuku#transactRemote(Parcel, Parcel, int)} for binder calls and {@link Shizuku#bindUserService(UserServiceArgs, ServiceConnection)}
 * for complicated requirements.
 * <p>This method is planned to be removed from Shizuku API 14.
 */

So I'm guessing this is a big disclaimer telling the developers to avoid using that. However, in BIT:

fun executeCommand(command: String): Process {
	// I tried working with a Shizuku user bound process and using hidden APIs, but did not
	//  fully get it to work, so I just use the same commands as I did when using SU.
	val process = Shizuku.newProcess(
		command.split(' ').toTypedArray(),
		null,
		null
	)
	process.waitFor()
	return process
}

So I'm guessing here you tried but had to fall back to newProcess.

Revoking Shizuku permission from BIT fixes Shizuku, but I'd like to continue using BIT :-)

Before I continue debugging (and maybe fix) this, I'd like to know what you think about next steps:

• find out why these processes pile up, possibly finding a Shizuku bug (but the disclaimer in Shizuku API makes me worried)
• replace newProcess with proper (I don't know what yet, I'm still new to Shizuku) Shizuku API

EDIT: for the moment I worked around the bug by commenting the call to getConnectedWifiSSID.

[daniele-athome]

I forgot to add:

• both Shizuku and BIT have battery restrictions disabled
• "Disable child process restrictions" in developer settings is enabled - disabling it doesn't affect anything apparently

[CasperVerswijvelt]

Somehow completely missed this issue, sorry about that.

Is this still something you have regularly? While I don't know why this command would hang, maybe we could manually kill the created dumpsys process after a specific timeout or when a new dumpsys process is started

I'm open to doing it the right way though and switching away from newProcess, if someone wants to take a crack at this (ideally an implemantation that works for both root and Shizuku)

[daniele-athome]

Is this still something you have regularly? While I don't know why this command would hang, maybe we could manually kill the created dumpsys process after a specific timeout or when a new dumpsys process is started

Well, I did comment the relevant code, so I'm working with a "crippled" version now so it doesn't have the bug. I'll try again with the latest version but since the relevant code didn't change, I guess it will still happen.

I'm open to doing it the right way though and switching away from newProcess, if someone wants to take a crack at this (ideally an implemantation that works for both root and Shizuku)

I'll get on it then :-)