#2603

User service processes leak (parented to init, never reaped) when client app is killed or server restarts

Openaioueopened 13d ago

Environment

  • Shizuku server: 13.6.0.r1086 (moe.shizuku.privileged.api)
  • Device: GrapheneOS Pixel 8a, Android 16
  • API library: dev.rikka.shizuku:api:13.1.5

Repro

App binds a user service the documented way:

Shizuku.UserServiceArgs(ComponentName(context, UserService::class.java))
    .processNameSuffix("sh")
    .daemon(false)
    .version(1)

Then, repeatedly over several days:

  • kill the client app while the service is bound (am force-stop, or pm install replacing the APK), and/or
  • restart the Shizuku server (wireless debugging restart).

Observed

Each cycle leaks a user-service process named <package>:sh:

  • reparented to pid 1 (parent is no longer shizuku_server)
  • running as shell uid
  • 40-93MB RSS each
  • survives Shizuku server restarts indefinitely, never reaped by anything

After 2 days of install/force-stop cycles on one device: 42 leaked processes (~2-3GB RSS before shared-page accounting).

shell        427     1 ... S net.aioue.utiliti:sh
shell       1814     1 ... S net.aioue.utiliti:sh
shell       2470     1 ... S net.aioue.utiliti:sh
... (42 total)
shell      31252     1 ... S shizuku_server

Expected

The server reaps its user-service children on client binder death, and on server shutdown/restart (the server knows the processes it spawned; they do not need to survive the server that owns them).

Related

  • RikkaApps/Shizuku-API#193 (same symptom with daemon(false)); it was closed referencing commit 5a9a5bc, which is a version bump, and a September 2026 comment there reports the same behaviour. The leak reproduces on the latest server (13.6.0), so it appears unresolved.

Workaround used in the meantime

The affected app (a) unbinds the user service after an idle period, and (b) has each freshly spawned user service sweep same-name leftover processes at bind time, so leaks self-heal. Happy to test any server-side fix on this device.

Activity

0

No activity yet.