No injection after a KernelSU emulated soft reboot spawns a duplicate daemon

[RMDycz]

Steps to reproduce/复现步骤

Install the latest version of the Vector module on a Redmi K80 Pro (HyperOS + Zygisk Next + KSU jailbreak environment).

Soft reboot the device.

In the license manager, click the "Action" / "Open" button for the LSPosed module.

Observe that the interface redirects to a Shell warning or becomes unresponsive, and the test module cannot be hooked.

Expected behaviour/预期行为

Correct startup and hooking
The v2.1 version of vector (vector-v2.1-3076 HSSkyBoy version) runs normally.

Actual behaviour/实际行为

Unable to start vector and unable to perform hooking

Xposed Module List/Xposed 模块列表

Module unrelated

Root implementation/Root 方案

Root access was gained by disabling SELinux through a Qualcomm 8E series vulnerability, followed by KSU entering jailbreak mode.

System Module List/系统模块列表

Vector v2.2 3080-88f8e1fa
Zygisk-next-780-9d7024c-release

Vector version/Vector 版本

Vector v2.2 3080-88f8e1fa

Android version/Android 版本

16 - xiaomi HyperOS 3

Version requirement/版本要求

• I am using the latest debug build from GitHub Actions./我正在使用 GitHub Actions 中最新的调试版本。

Logs/日志

locat-log.txt

[JingMatrix]

Please upload the log folder as indicated in #123.

[RMDycz]

The current situation is a bit abnormal.

I tried reinstalling the latest version of Vector and performing a soft reboot four times to reproduce the original problem. Each of these four tests yielded different results. The first two times, Vector crashed and failed to inject into the system framework. The third time, the DEX optimizer wrapper failed to mount. The fourth time, the problem reappeared after the reboot; Vector could not be opened. The logs should contain most of the logs from my tests from this morning to this afternoon.

verbose-log1.txt

@JingMatrix

[JingMatrix]

Let us enable only (Neo)Zygisk and Vector, do a full reboot, trigger Vector Action button, and then upload the whole folder /data/adb/lspd/log as logs (you have pack it in .zip by your own.)

[RMDycz]

Let us enable only (Neo)Zygisk and Vector, do a full reboot, trigger Vector Action button, and then upload the whole folder /data/adb/lspd/log as logs (you have pack it in .zip by your own.)

I understand, but I can only perform the following steps:

1. Uninstall the existing Vector

2. Perform a hardware reboot

3. Re-execute the vulnerability to jailbreak

4. Install Vector

5. Perform a soft reboot to make Vector effective

If I don't do this, a hardware reboot will cause the KSU jailbreak to disappear.
Can this solution find the problem?

[JingMatrix]

Yes, please do as you suggest. And remember to pack the logs for uploading.

[RMDycz]

Yes, please do as you suggest. And remember to pack the logs for uploading.

I have followed the procedure. The current situation is:

After a hardware reboot, reinstalling Vector and Vector runs normally.

However, a subsequent soft reboot causes the aforementioned problem.

The logs are attached; they should contain details of my two reboot attempts. The first reboot was normal, but the subsequent soft reboot caused the problem.

vector_logs.zip

[JingMatrix]

Thanks, these logs are exactly what was needed. Root cause is clear now.

The trigger is KernelSU's emulated soft reboot. It doesn't reboot the kernel — it runs stop, replays post-fs-data and services, then start. That tears down and respawns zygote (which is why NeoZygisk re-injects correctly), but it also re-runs every module's service.sh, including Vector's. The existing Vector daemon is a detached process, so stop doesn't kill it, and it has no idea a second service.sh was just fired. The result is two daemons: the survivor from the previous boot and a fresh one. Both claim the same rendezvous service, forward transactions to each other, and one crashes on a stack overflow. No framework gets injected, so the manager opens into the shell warning.

This also matches what you saw: the first soft reboot after installing works because there's no prior daemon; every soft reboot after that collides with the one already running.

[JingMatrix]

It is hard to find a solution, you will have to wait.

Currently, the only workaround for you, is to avoid soft-reboot from KernelSU

[RMDycz]

It is hard to find a solution, you will have to wait.

Currently, the only workaround for you, is to avoid soft-reboot from KernelSU

Why did some previous versions seem to have no problem? But overall, the issue isn't serious. Now that we know the cause, we can use the following temporary solution: disable vector in ksu, then perform a soft reboot, and then enable vector again and perform another soft reboot. This only requires an extra soft reboot.

[JingMatrix]

@RMDycz If you have some working version, please share the link and the logs generated by that build, it will help us to solve this in new versions of Vector.

[RMDycz]

@RMDycz If you have some working version, please share the link and the logs generated by that build, it will help us to solve this in new versions of Vector.

Okay, the Vector v2.1 (3076-1e595f3c-HSSkyBoy) version I mentioned before also has the same problem. However, I can confirm that Vector 2.0 Mar 23 version does not have this issue because I have been using this version for a considerable period of time.

[RMDycz]

@RMDycz If you have some working version, please share the link and the logs generated by that build, it will help us to solve this in new versions of Vector.

This could also be an issue with the KSU update, because the KSU version I was using before was an older one, probably the May version of Vector and the May version of KSU. It might take some time to test the versions to find out exactly where the problem lies.