我这的问题一无限重启，问题二 riru 不生效

[NewBugger]

问题一

开了 riru 后，会遇到这样的无限重启： 开机进系统，然后过几秒后就会不完全重启（进开机画面跑一下后又要解锁进系统） 然后重复以上过程 测试发现，先关掉 work profile 再重启就不会出现无限重启，事后再开启 work profile 也无异常

问题二

但是，明明 riru 模块已经启用了，“riru not found in memory” 模块安装时应该没问题的 magisk 日志：

03-31 22:57:32.107   699   699 I Magisk  : Magisk v17.3(17302) daemon started
03-31 22:57:32.141   699   700 I Magisk  : ** post-fs-data mode running
03-31 22:57:32.141   704   704 I Magisk  : Magisk v17.3(17302) logger started
03-31 22:57:32.142   699   700 I Magisk  : * Mounting /data/adb/magisk.img
03-31 22:57:32.289   699   700 I Magisk  : * Running post-fs-data.d scripts
03-31 22:57:32.290   699   700 I Magisk  : * Running module post-fs-data scripts
03-31 22:57:32.555   699   700 I Magisk  : riru-core: exec [post-fs-data.sh]
03-31 22:57:32.578   699   700 I Magisk  : riru_storage_redirect: exec [post-fs-data.sh]
03-31 22:57:42.820   699   962 I Magisk  : ** late_start service mode running
03-31 22:57:42.852   699   962 I Magisk  : * Running service.d scripts
03-31 22:57:42.856   699   968 I Magisk  : * Starting MagiskHide
03-31 22:57:42.856   699   968 I Magisk  : hide_utils: Hiding sensitive props
03-31 22:57:42.870   699   968 I Magisk  : hide_list: [com.google.android.gms.unstable]
03-01 16:33:47.122   699   968 I Magisk  : proc_monitor: com.google.android.gms.unstable
03-01 16:34:14.207   699   968 I Magisk  : proc_monitor: com.google.android.gms.unstable

目前没电脑，晚上提个 adb log 过来

环境： LineageOS official 15.1 Magisk 17.3 （18 改动太多，就没追更新）

[NewBugger]

问题三

如果开启了 riru 模块的话，需要挂载 automount=true 的模块会失效 例如我上面的 magisk 日志中没有原本应有的 noto cjk 模块

[RikkaW]

v17 的 riru_storage_redirect 有几个小时下载到的会是有问题的，先重新下载安装试一下（

[NewBugger]

我的锅我没说清楚，我以上说明都是指的 riru core, 只要开启了就会出事。。

[RikkaW]

可是明明上面 log 里有（

[RikkaW]

凄惨说明一下一开始看到这个的想法：

关于问题一，从 v14 的 Riru 开始增加了如果没有在 zygote 进程中检测到 Riru 就自动重启 zygote，这个过程在 Magisk 提供的 post-fs-data.sh 中进行，并且开始还会等两秒（所以就有了开机之后又重启的现象）。但 post-fs-data 应该只会执行一次，不至于造成无限重启。

关于问题二，根据日志似乎是 riru_storage_redirect: exec [post-fs-data.sh] 这步卡住了。某个版本之后的这个模块的 post-fs-data.sh 增加了等待有 Riru 的 zygote 进程的行为。 而 Magisk 在进行 post-fs-data 的过程时是这样的行为，先执行并等待每个模块的 post-fs-data.sh，再进行每个模块的 auto mount。在这个过程中，一旦有某个模块的 post-fs-data.sh 不结束，后续的步骤就会无法进行。 所以为了不让这样的情况发生，post-fs-data.sh 大概写成了这样：

if [[ $1 != "background" ]]; then
    sh $0 background &
    exit 0
fi

# 真正干活

但在之前某一天的某几个小时，下载到的整个模块会是有问题的（少了 exit 0），就会卡住 Magisk 的 post-fs-data 过程。所以这个脚本永远等不到有 Riru 的 zygote 进程，就永远不会结束，而不会结束 Magisk 就无法进行后续的挂载，也就无法出现要等的有 Riru 的 zygote 进程。

当然还有另外的可能，下载到没问题的模块，但你的 sh 不能正确执行上面那段。对于这个 v18 的 sr 模块会改为在 native 部分进行等待有 Riru 的 zygote 进程的过程，就一定不会有卡住 Magisk 的 post-fs-data 过程的问题。

但但但但，如果真的像上面所说，只有 core + 开了 work profile = 无限重启，那就猜不到原因了（

[NewBugger]

谢详细解答

我的尝试

问题一实在莫名其妙，昨天正好 Los 16 出来，就升级到了 Pie（不上 riru 不死心 依旧保持 magisk 17.3 版本，开机卡在启动画面 把 magisk 换到了 Magisk debug canary 频道的最新 18.2 版本，却发现能用了，什么问题都没有了 虽然我以为这并不能作为 “magisk 17.3 不支持 riru” 的假设。和问题一的现象不一样也说明可能和系统版本有关

回复

并且开始还会等两秒（所以就有了开机之后又重启的现象）。但 post-fs-data 应该只会执行一次，不至于造成无限重启 但但但但，如果真的像上面所说，只有 core + 开了 work profile = 无限重启，那就猜不到原因了（

是的，太难猜

但在之前某一天的某几个小时，下载到的整个模块会是有问题的（少了 exit 0）

我是前天下午在 riru 和 sr-assets releases 下载的

当然还有另外的可能，下载到没问题的模块，但你的 sh 不能正确执行上面那段

有可能是 magisk 17.3 的问题；排除模块冲突的情况，只留下 riru-core 也一样出事；应该也不是系统版本的问题（失误了没在 8.1 测 18.2）

以上，我还是佛了吧。虽然很希望 magisk 17.3 能够用上 riru，不是为了日卡卡我也不会更新

[RikkaW]

说起来现在怎么样了（

[NewBugger]

啊抱歉我还以为我说过。

我之后的测试结果是，不能在 Magisk 18 版本以下使用 riru core。

[NewBugger]

依旧保持 magisk 17.3 版本，开机卡在启动画面。把 magisk 换到了 Magisk debug canary 频道的最新 18.2 版本，却发现能用了，什么问题都没有了。虽然我以为这并不能作为 “magisk 17.3 不支持 riru” 的假设。

还真说过。

之后我就没用过 magisk 旧版本了，新旧版本区别太大我也不方便再回去测试。