Termux 里跑起来的 sshd、定时任务、自己写的 Python 小服务，只要手机重启一次，全部得手动再拉一遍——这个痛点几乎所有把 Termux 当轻量服务器用的人都撞过。我前后在三四台设备上折腾过 Termux 服务自启动，从最早在 bashrc 里塞一堆 if 判断的土办法，到后来把 Termux:Boot 和 termux-services 两条线彻底分开处理，中间踩的坑足够写满一页笔记。这篇就聊聊怎么让 Termux 里的服务在开机后自己站起来，以及为什么大部分人的第一次尝试都会失败。
需要先说清楚定位：这篇文章不解决"Termux 能不能当服务器"的问题，只解决"服务怎么在重启后自动恢复"这一个环节。适合已经能在 Termux 里手动跑起 sshd 或者自定义脚本、但每次重启都要重新登录手动敲命令的人。如果你刚装好 Termux 还没跑通任何服务，建议先把服务手动跑通，再回来处理自启动，否则排查问题时变量太多。
1. Termux 的进程活不过一次重启，这件事得先讲清楚
1.1 Android 是怎么对待 Termux 这类"后台终端"的
很多人对 Termux 的第一误解，是把它当成一台"手机上的 Linux 服务器"。实际上 Termux 是运行在 Android 应用沙箱里的一个普通 App，它没有 root，也不注册系统服务，所有进程都挂在 Termux 这个应用进程的生命周期下面。Android 在重启后会重建整个系统，Termux 的进程自然全部消失，$PREFIX/var/run里的 pid 文件、socket 文件也都跟着没了。这不是 bug，是设计如此。
更重要的是，Android 对后台应用有一套自己的管控逻辑。系统会把长期处于后台、又不属于前台服务的应用判定为"可以回收"，在内存紧张或者进入 Doze 模式时直接冻结甚至杀掉。这意味着哪怕你不重启手机，只是锁屏放了几个小时，Termux 里的服务也可能被挂起。所以"服务自启动"这件事在 Termux 上其实有两个层面：一是重启后怎么自动拉起来，二是拉起来之后怎么让它别被系统掐死。后面会分别讲。
从系统层面看，Termux 唯一能拿到的"开机信号"，来自 Android 的BOOT_COMPLETED广播。普通应用想接收这个广播，必须在清单文件里静态注册接收器，而 Termux 主程序本身并没有做这件事——做这件事的是它的配套插件 Termux:Boot。理解了这一点，后面所有方案的设计思路就顺了：要么借助插件在开机广播里执行脚本，要么在 Termux 内部用一个常驻的进程管理器维持服务，要么两者结合。
1.2 不自启动会带来哪些真实的麻烦
我在最初用 Termux 跑一个简单的文件同步脚本时，根本没在意自启动。当时的用法是每天晚上手动打开 Termux，敲一行命令启动，用完就关。直到有一次出差三天，回来发现同步停了三天，数据对不上，才开始认真处理这个问题。服务不自启动的代价，往往是"隐性"的：你不会立刻发现它挂了，等到需要用到的时候才发现某个端口连不上、某个定时任务没执行。
具体来说，常见的麻烦有这么几类。第一种是远程连接类服务，比如 sshd，重启后端口不再监听，外面的连接直接被拒绝，而且因为服务没起来，你也没法通过它进去排查。第二种是定时任务类，crond 没起来，所有 cron 条目静默失效，日志里连报错都没有。第三种是长驻后台任务，比如一个轮询接口的小脚本、一个本地 Web 服务，它挂了就是挂了，没有任何提示。
还有一个容易被忽略的点：即使你用脚本把服务拉起来了，如果启动顺序不对，服务也可能因为依赖没就绪而立刻退出。比如你的脚本依赖某个目录挂载完成，或者依赖网络可用，在开机阶段这些条件可能还不满足。这也是为什么我不建议把所有东西都塞进一个开机脚本里一把梭，而是分层处理。
1.3 为什么"把命令写进 bashrc"是个坏主意
网上能搜到的最简方案，是在~/.bashrc或者~/.profile里加一段判断：如果服务没跑就启动它。这个方案看起来很省事，但问题很致命。首先，Termux 的 shell 配置文件只在交互式登录时才会被读取，也就是说你得先手动打开 Termux 一次，脚本才会执行——这根本不叫自启动，叫"手动启动的自动化"。其次，每次打开新终端窗口都可能重复触发启动逻辑，容易造成端口冲突和进程重复。
我早期就踩过这个坑：把 sshd 的启动命令写进 bashrc，结果每次开新会话都尝试启动一次，虽然 sshd 有端口占用保护不会真的起两个，但sv之类的服务管理器会被反复调用，日志里刷满了重复记录，排查真正的问题时非常干扰。所以我的建议很明确：shell 配置文件只用来设置环境变量和别名，不要用它做进程管理。
2. 先选路线：Termux:Boot、termux-services、外部触发器各自适合谁
2.1 Termux:Boot 做的其实是"重启时跑一次脚本"
Termux:Boot 是一个独立的 APK，需要单独安装，它的职责非常单一：在系统开机完成后，按顺序执行~/.termux/boot/目录下的所有可执行脚本。它不负责保持服务存活，也不负责崩溃重启，就是开机跑一遍。正因为职责单一，它反而是最可靠的一环——它挂在系统广播上，不受 Termux 内部进程状态影响。
这里有个关键前提：Termux:Boot 安装之后必须手动打开一次应用图标，让系统完成接收器的注册。这一步很多人会漏掉，装完就等着重启，结果开机毫无反应。原因是 Android 对于从未启动过的应用，在很多定制系统上会限制其接收开机广播。手动打开一次，相当于告诉系统"这个应用是活的"，之后它才能收到BOOT_COMPLETED。
它的执行环境也需要注意。脚本运行时的工作目录不是$HOME，PATH 也可能不完整，所以脚本里所有命令最好写绝对路径，或者开头统一export PATH=$PREFIX/bin:$PATH。另外，~/.termux/boot/里的脚本必须加可执行权限，chmod +x这一步漏掉的话，文件会被静默跳过，不报任何错。
2.2 termux-services 管的是"进程活着并持续活着"
termux-services 是 Termux 官方提供的一个包，内部用的是 runit 这套轻量进程管理方案。它解决的问题和 Termux:Boot 完全不一样：它不管你什么时候启动，只管一个服务被sv-enable之后，是不是一直处于运行状态；如果进程意外退出，它会自动重新拉起。这对那些会崩、会退出的服务来说非常关键。
runit 的模型很简单：每个服务在$PREFIX/var/service/下有一个自己的目录，目录里放一个叫run的可执行脚本，脚本负责用exec启动前台进程。runit 监控这个进程，进程一退出就重新执行run。日志则交给同目录下的log/run脚本处理，默认会落到$PREFIX/var/log/sv/下面。
我个人的用法是把这两者组合起来：Termux:Boot 负责在开机后把整体环境准备好，然后调用sv up把关键服务拉起来；termux-services 负责后续的存活与重启。两条线各管一段，职责清晰，出问题的时候也容易定位是哪一段没起作用。
2.3 三条路线的对照与组合方式
除了上面两条主线，还有一种"外部触发器"思路：用系统的自动化工具，或者从别的设备发一条消息过来触发启动。这种方式我不太推荐作为主力，因为它引入了外部依赖，网络不通、对方设备关机都会导致触发失败，但在调试阶段可以用来验证服务本身能不能跑起来。
| 方案 | 触发时机 | 是否能保活 | 适合场景 | 主要短板 |
|---|---|---|---|---|
| Termux:Boot | 系统开机后 | 否 | 初始化环境、拉起脚本 | 需手动首次打开，不保活 |
| termux-services | 手动或脚本调用 | 是 | sshd、crond、常驻进程 | 依赖 Termux 进程存活 |
| 外部触发器 | 任意时刻 | 否 | 远程调试、兜底补救 | 依赖网络和第三方 |
选型上的经验是：不要指望单一方案解决所有问题。最稳的组合是 Termux:Boot 做初始化 + termux-services 做托管 + 系统电池优化白名单做保活，三层叠起来，我能做到一周不手动干预，服务基本都在。
3. 把 Termux:Boot 跑通：从安装到脚本能被执行的每一步
3.1 安装之后必须做的那一次手动打开
安装 Termux:Boot 的渠道，稳妥的是从官方发布的 APK 源获取，注意版本要和你当前 Termux 主程序的签名来源保持一致——如果主程序和插件来自不同的签名源，两者会互相不认，脚本不会被执行。这一点在混装不同来源包的时候特别容易出问题，我见过有人因为主程序和一个插件来自不同渠道，折腾一晚上找不到原因。
装完之后，点开 Termux:Boot 的图标，界面通常是一闪而过或者显示一个简单说明，这就够了，说明系统已经登记了这个应用。接下来去系统设置里找到 Termux 和 Termux:Boot 的电池管理，把"允许后台活动"打开，把"省电策略"设为无限制。不同厂商的定制系统叫法不一样，有的叫"自启动管理"，有的叫"后台运行权限"，位置一般在应用详情页或者安全中心里。
最后一步是验证。先手动在~/.termux/boot/下放一个最简单的脚本，内容就是往一个文件里写一行时间戳。然后重启手机，重启后不用打开 Termux，直接用文件管理器或者下次打开 Termux 后查看那个文件有没有更新。这一步能确认整条链路是通的，之后再往里加真正的服务启动逻辑。
3.2 ~/.termux/boot/ 目录下的脚本规范
脚本执行顺序是按文件名的字典序来的，所以如果你有多个脚本且存在依赖关系，建议用00-、10-、20-这样的前缀编号，让执行顺序一目了然。我习惯把环境准备类的放前面，网络等待类的放中间，服务启动类的放后面，这样出问题时按顺序看日志就能定位到哪一段断了。
一个典型的启动脚本大概长这样，注意每一行的意图：
#!/data/data/com.termux/files/usr/bin/bash # 00-prestart.sh：开机后先准备环境，不启动任何服务 export PATH=/data/data/com.termux/files/usr/bin:/data/data/com.termux/files/usr/bin/applets:$PATH export HOME=/data/data/com.termux/files/home cd "$HOME" || exit 1 # 申请唤醒锁，避免刚起来就被系统挂起 termux-wake-lock # 等网络可用，最多等 60 秒 for i in $(seq 1 60); do if ping -c 1 -W 1 1.1.1.1 >/dev/null 2>&1; then break fi sleep 1 done # 记录时间戳，方便确认脚本确实执行过 date >> "$HOME/boot.log"关于 shebang，直接写#!/usr/bin/env bash在开机环境下有可能失败，因为那个时刻 PATH 还没配好。写完整的$PREFIX/bin/bash绝对路径是最保险的。同理，脚本里所有外部命令要么写绝对路径，要么在最前面把 PATH 导出完整。
权限方面，chmod +x是必须的。另外还要注意，脚本所在目录是~/.termux/boot/，不是~/.termux/，新建目录的时候别建错层级。文件名不要带后缀其实也行，但为了可读性我一般保留.sh。
3.3 唤醒锁、重定向与"脚本执行了但你看不到"的问题
termux-wake-lock这个命令值得单独说。它由 Termux 主程序提供，作用是申请一个唤醒锁，让 CPU 在锁屏状态下不完全休眠。对于 Termux:Boot 脚本来说，它几乎是必需品：开机后系统很快会进入低功耗状态，如果此时你的脚本还在等待网络或者启动服务，很可能被直接挂起，表现就是"服务有时候起来有时候不起来"，非常随机。
另一个常见问题是脚本执行了但没有输出，所以你看不到任何反馈。原因很简单，开机脚本的标准输出没有连接到任何终端，全都丢掉了。解决办法是在脚本里显式重定向。我通常这么处理：
exec >> "$HOME/boot.log" 2>&1放在脚本开头，这样后面所有的输出和报错都会追加到日志文件里。排查的时候只需要tail -f ~/boot.log，非常直观。要注意这个日志文件会一直增长，长期运行的话加个简单的轮转，或者在脚本里定时清空。
还有一类问题是"脚本前半段跑通了，后半段没跑"。这通常是因为脚本中途遇到了返回非零的命令，如果脚本开头写了set -e，后面所有内容都会直接终止。开机脚本里我建议不要用set -e，而是对关键步骤手动判断返回值并记录，保证一个环节失败不会拖垮整个流程。
4. 用 termux-services 托管常驻服务：sshd、crond 和自定义进程
4.1 安装与初始化，为什么要重启一次 Termux
安装很简单，一条命令：
pkg install termux-services装完之后要做的是完全退出 Termux 再重新打开。注意"完全退出"指的是从最近任务列表里划掉，或者用exit退出所有会话，而不是简单地切到后台。原因是 termux-services 需要启动一个常驻的service-daemon进程，这个进程由 shell 登录时的启动钩子拉起，只有重新进入 Termux 才会触发。很多人装完之后直接敲sv命令发现报错，八成就是没重启 Termux。
验证 daemon 是否在跑，可以用ps aux | grep service-daemon看一下，或者直接sv status看有没有输出。如果 daemon 没起来，sv命令要么提示找不到服务目录，要么干脆无响应。这个前置条件必须确认，否则后面所有 sv 操作都是白费力气。
还有一点需要明白：termux-services 的进程本身也活在 Termux 应用进程里。它能在 Termux 被系统杀掉之后自己复活吗？不能。所以它必须配合 Termux:Boot 使用，由开机脚本在环境准备好之后重新把整个服务体系拉起来。这是两层结构，缺一不可。
4.2 sv 命令族与 sv-enable 的实际差别
sv系列的用法看着多，其实记住几个就够：
| 命令 | 作用 | 使用频率 |
|---|---|---|
sv-enable <服务名> | 创建启用标记，让 daemon 自动拉起 | 高 |
sv-disable <服务名> | 取消启用标记 | 中 |
sv up <服务名> | 立即启动一次 | 高 |
sv down <服务名> | 立即停止 | 中 |
sv restart <服务名> | 重启 | 中 |
sv status <服务名> | 查看状态和运行时长 | 高 |
这里的关键差别在sv-enable和sv up上。sv up只是当下启动一次，重启或者 daemon 重启之后不会自动恢复；sv-enable是在服务目录下建立一个启用标记，daemon 每次启动时会去扫描这些标记，把带标记的服务拉起来。所以如果你希望服务在每次开机后自动运行，必须用sv-enable，只做sv up是不够的。
实际操作里我会先sv up验证服务能正常起来，确认端口监听和日志都没问题之后，再执行sv-enable把它固化下来。这个顺序能避免服务本身有问题却被自动反复重启，日志被刷爆。
4.3 自己写一个 run 脚本：结构、退出码与重启策略
如果 termux-services 里没有现成的服务定义，比如你要托管一个自己写的 Python 脚本，就得手动建服务目录：
mkdir -p $PREFIX/var/service/mypy cd $PREFIX/var/service/mypy然后创建run文件，内容大致如下：
#!/data/data/com.termux/files/usr/bin/sh exec 2>&1 exec /data/data/com.termux/files/usr/bin/python \ /data/data/com.termux/files/home/apps/mypy/main.py关键点是最后那个exec。runit 要求run脚本把服务进程"替换"成前台进程，也就是说脚本执行完之后，进程要变成你的服务本身，而不是脚本的子进程。如果写成不 exec 的形式，脚本跑完就退出了，runit 会认为服务结束，然后不停地重新执行，表现就是服务反复重启，日志里全是重复的启动记录。
exec 2>&1那一行是把标准错误合并到标准输出，方便日志被统一收集。日志目录的默认位置是$PREFIX/var/log/sv/mypy/，日志工资会自己创建。如果你需要自定义日志处理，可以在服务目录下再建一个log/run。
关于重启策略，runit 的行为是：进程退出后立即重新执行 run 脚本，中间有很短的间隔。如果你的服务因为配置错误一直在秒退，就会形成快速重启循环，日志飞速膨胀。所以第一次托管新服务时，我建议先不加sv-enable，只用sv up观察几分钟的日志，确认稳定了再固化。
5. 服务没起来时，我一般按这个顺序往下查
5.1 第一步永远是确认脚本有没有被执行
服务没起来的时候，不要急着去改服务本身的配置，先确认最外层——开机脚本到底跑了没有。方法就是在脚本开头加一行写时间戳的命令，重启后看这个时间戳是不是最新的。如果没更新，问题在 Termux:Boot 这一层，跟你的服务代码没有任何关系。
这一层的排查顺序是：确认应用是否手动打开过、确认后台运行权限是否放开、确认脚本是否有可执行权限、确认脚本所在目录是否正确。这四点覆盖了我遇到的绝大多数"完全没反应"的情况。其中最容易忽略的是第二点，尤其在国内定制系统上，默认的后台限制非常严格，不手动放开的话，开机广播根本送不到应用。
另外可以留意一下系统日志里是否有相关记录。部分设备可以通过开发者选项或者系统日志工具看到广播的分发情况，如果能看到 Termux:Boot 收到广播但没有执行脚本，那问题就锁定在脚本本身而不是权限上。
5.2 进程起来了又消失：Doze、电池优化与内存回收
这个现象非常典型：重启后你打开 Termux，看到服务在跑，锁屏放一晚上，第二天早上服务没了。这不是自启动失败，而是保活失败。Android 的 Doze 模式会在设备静止且屏幕关闭一段时间后，限制后台应用的网络和 CPU 活动，普通的后台进程会被冻结。冻结时间长了，系统可能直接回收。
应对办法有几步。首要的是把 Termux 加入电池优化白名单，路径一般在系统设置的电池或者应用管理里，名称类似"不受限制""允许后台活动"。其次是在服务运行期间保持唤醒锁，也就是让脚本在启动服务之前先调用termux-wake-lock。唤醒锁的代价是耗电增加，但对于需要长期在线的小服务来说，这个代价值得。
需要说明的是，即使做了这些，也不能保证 100% 不被回收。不同厂商的系统策略差异很大，有的设备对后台进程特别激进。我的经验是，如果服务本身允许中断，就接受偶尔被回收的现实，配合一个外部的健康检查机制定期确认；如果服务绝对不能中断，那手机本身就不适合作为承载设备，应该换到更稳定的环境。
5.3 端口冲突、重复拉起与残留进程
还有一个隐藏问题：服务在重启前的旧进程并没有真正消失时，新启动的进程会因为端口被占而失败。虽然在设备重启的场合下这种情况很少，但在"手动重启 Termux 应用"或者"从后台恢复"的场景下就会出现，因为那时旧进程可能还挂在系统里。
排查方式是看端口监听情况，ss -lntp或者netstat -lntp都可以，注意观察同一端口是否有多个监听项，或者是否有属于已退出进程的僵尸监听。如果是 termux-services 托管的服务，还要注意不要既用了sv-enable又在开机脚本里手动调用一次启动命令，两者叠加会导致同一服务的两个实例互相抢端口。
我自己就犯过这个错：先用 termux-services 托管了服务，又在开机脚本里写了一遍启动命令，结果就是其中一路永远起不来，日志里一堆"地址已被占用"。后来统一约定：凡是被 termux-services 托管的服务，开机脚本里只调用sv up，不直接执行服务本身的启动命令。
6. 让自启动真正稳下来的一些加固手段
6.1 日志落到文件，别指望终端里能看到
开机阶段的输出不会被任何地方接收，所以日志必须主动落盘。我的做法是在两个层面都做重定向：Termux:Boot 的开机脚本里统一把输出追加到~/boot.log，termux-services 托管的服务则由 runit 自动收集到$PREFIX/var/log/sv/下。这两份日志的职责不同，前者记录"开机流程走到哪一步"，后者记录"服务运行状态和崩溃原因"。
查看日志的时候有个小技巧：runit 的日志目录下通常会有current这个文件，它是当前正在写入的日志，直接tail -f它比看轮转后的文件更及时。如果服务反复重启，current里会密集出现重复的启动信息，一眼就能看出来是快速重启循环。
日志长期不清会撑爆存储，尤其是那些启动失败后疯狂重试的服务。我一般在服务稳定之后加一条 cron 定时清理，或者干脆在开机脚本里做一次简单的日志截断，保留最近一定行数。
6.2 延迟启动与依赖等待
开机阶段最容易出的问题是"启动太快"：网络还没就绪、存储还没挂载完、系统还在忙着跑其他初始化任务，这时候拉起的服务可能拿不到需要的资源就直接失败了。解决办法是在脚本里加入等待逻辑，而不是写一个固定长度的sleep。
固定 sleep 的问题是两头不讨好：设短了不够，设长了拖慢整体启动。我更倾向于写轮询等待，比如前面那段等待网络连通的循环，最多等 60 秒，一旦通了就立刻继续。对于依赖本地文件的场景，就是轮询判断文件是否存在；对于依赖某个端口的场景，就是循环尝试连接。这种写法比盲等要可靠得多，而且失败的时候日志里能明确记录"等了多久还是没等到"，方便判断是资源问题还是超时设置不合理。
对于服务之间的依赖，比如 A 服务必须先起、B 服务才能起，可以在 B 的服务定义里加一个前置检查，或者在开机脚本里先确认 A 的状态再拉起 B。runit 本身对依赖的处理比较弱，复杂场景下我倾向于在脚本层面用手动判断来解决。
6.3 路径、环境变量和存储权限的坑
Termux 的路径结构和普通 Linux 差别很大，$PREFIX指向的是应用私有目录，$HOME也是一个应用内的路径。这些路径在开机脚本里如果写成硬编码，一旦遇到设备变更或者应用重装就可能失效。所以脚本里我尽量用变量，并且在脚本开头把PREFIX、HOME、PATH都显式导出一次。
涉及外部存储的服务还要特别注意权限。较新的 Android 版本对应用访问外部存储有严格限制，Termux 需要单独申请存储权限，而这个权限申请是交互式的，重启之后不会自动恢复。如果你的服务依赖外部存储目录里的文件，最好的做法是把数据放在应用私有目录里，避开这个权限问题。实在需要外部存储的话，要提前在应用里执行一次权限授予操作，并确认开机后权限仍然有效。
还有一个和路径相关的小坑：部分脚本在交互式 shell 里能跑通，放到开机脚本里就报"命令找不到"，原因往往就是 PATH 不同。解决办法前面已经提过，统一导出 PATH 或者写绝对路径。这个坑我踩过不止一次，现在养成了习惯——写开机脚本时，把所有外部命令的路径都先用which查清楚，然后写死在脚本里。
6.4 Proot 容器内的服务要不要单独处理
顺带聊一个常被问到的问题：如果服务是跑在 proot 环境里的发行版里面，自启动该怎么做。答案是容器内部不需要、也没办法自己处理开机启动，因为 proot 只是一个用户态的路径转换层，里面没有 init 系统，容器里的进程本质上还是宿主机 Termux 进程的子进程。所以正确的做法是由宿主机的开机脚本负责把容器环境拉起来，再在里面执行启动命令。
我的处理方式是在开机脚本里写一段类似这样的逻辑：先启动 proot 容器并进入，执行容器内的服务启动命令，然后保持这个进程前台运行，交给 termux-services 托管。如果要让容器内的服务也能崩溃重启，就需要在外层用 termux-services 包一层，而不是在容器内部搞一套进程管理，那样在 proot 环境下是跑不起来的。
6.5 一次完整的验证流程
改完配置之后，我不建议直接重启设备验证，太慢了。更高效的方式是分三段验证。第一段，在 Termux 里手动执行一次开机脚本，看服务能不能正常起来，这验证脚本逻辑本身是否正确。第二段，手动停掉服务再重启 Termux 应用，看 termux-services 的 daemon 有没有按预期把服务拉起来，这验证托管配置。第三段才是真正重启设备，验证 Termux:Boot 这条链路。
这三段分开验证的好处是，每一步失败时你都知道是哪一层的问题，不用在重启的漫长等待里反复猜测。我现在的习惯是每次调整配置后都走一遍这三段，虽然多花几分钟，但省下来的排查时间远不止这点。
顺便说个我自己一直在用的小技巧：让开机脚本每次执行时都写一行标记，内容包括执行时间和当时的服务状态摘要。这样积累一段时间之后，我只要看一眼这个日志，就能知道过去几天里设备重启了几次、每次服务是不是都正常起来了。这个习惯帮我发现过一次隐藏的问题——某段时间服务其实每天都会重启一次，只是我平时不打开 Termux 所以没注意到，日志一看就露馅了。
