ASP.NET Core Native AOT + systemd 实战：把 Linux ARM64 程序变成可靠的设备服务

ASP.NET Core Native AOT + systemd 实战：把 Linux ARM64 程序变成可靠的设备服务

前言

前面的文章已经完成了应用内部的主要架构：

ASP.NET Core Host
        │
        ├── Minimal API
        │
        ├── Application Service
        │
        ├── BackgroundService
        │
        ├── Runtime State
        │
        └── Infrastructure

Native AOT 编译之后，我们最终得到一个 Linux ARM64 可执行程序。

例如：

DeviceWeb

于是很容易产生一个想法：

./DeviceWeb

程序能够启动。

是不是部署就完成了？

显然不是。

真正运行在 Linux 设备上的程序通常需要满足：

设备启动
   ↓
应用自动启动

应用运行
   ↓
统一日志

应用退出
   ↓
正确清理资源

异常崩溃
   ↓
自动恢复

系统关机
   ↓
优雅停止

这已经不是 ASP.NET Core 本身应该解决的问题。

它属于：

Process Supervision

在现代 Linux 系统中，承担这个职责的通常就是：

systemd

这一篇就把：

ASP.NET Core
Native AOT
Linux
systemd
journald

完整串起来。

---

一、为什么不能简单使用 &

最简单的后台运行方式可能是：

./DeviceWeb &

这样 Shell 返回：

$

程序似乎已经在后台运行。

但问题很多：

谁负责启动它？

谁知道它是否还活着？

异常退出以后怎么办？

设备重启以后怎么办？

日志在哪里？

怎么停止？

怎么重新启动？

程序属于哪个用户？

环境变量在哪里配置？

所以：

./DeviceWeb &

只是：

Background Process

不是：

Managed Service

---

二、systemd 到底是什么

很多开发者第一次接触 systemd，只把它理解成：

开机启动工具

实际上它承担的职责远不止如此。

可以简单理解成：

systemd 是 Linux 用户空间中的系统和服务管理器。

对于我们的 ASP.NET Core 程序：

systemd
   │
   ▼
DeviceWeb

systemd 成为这个进程的：

Process Supervisor

负责：

Start
Stop
Restart
Dependency
Environment
Identity
Logging
Resource Management

等生命周期管理。

---

三、ASP.NET Core 和 systemd 的职责边界

这个边界非常重要。

ASP.NET Core 负责：

Application
│
├── HTTP
├── BackgroundService
├── Business Logic
├── Runtime State
└── Graceful Shutdown

systemd 负责：

Process
│
├── Start
├── Stop
├── Restart
├── User
├── Environment
├── Dependency
└── Process Supervision

所以：

systemd
   ↓
ASP.NET Core Host
   ↓
Application

形成三层结构：

Operating System
      ↓
systemd
      ↓
ASP.NET Core Host
      ↓
Application Runtime

---

四、Native AOT 在这里有什么优势

普通 Framework-dependent .NET 应用可能需要：

dotnet DeviceWeb.dll

目标系统还需要对应的：

.NET Runtime

Native AOT 发布以后通常得到：

ELF Executable

systemd 可以直接：

ExecStart=/opt/device-web/DeviceWeb

因此部署模型非常简单：

systemd
   ↓
Native ELF

而不是：

systemd
   ↓
dotnet
   ↓
CLR
   ↓
DeviceWeb.dll

---

五、推荐的 Linux 目录结构

不要把程序随便放在：

/root
/home
/tmp

可以建立明确目录。

例如：

/opt/device-web/
│
├── DeviceWeb
├── wwwroot/
└── appsettings.json

应用程序：

/opt/device-web

运行时数据：

/var/lib/device-web

日志原则上交给：

journald

因此形成：

/opt/device-web
    ↓
Application

/var/lib/device-web
    ↓
Persistent Runtime Data

journald
    ↓
Logs

这是一个非常清晰的 Linux 部署模型。

---

六、为什么程序和数据要分开

例如：

/opt/device-web

应该主要包含：

程序
静态资源
默认配置

而：

/var/lib/device-web

保存：

用户配置
设备运行数据
持久化状态

这样升级程序：

replace /opt/device-web

不会自然要求覆盖：

/var/lib/device-web

里的用户数据。

也就是说：

Application Binary
≠
Persistent Data

这是设备升级设计里非常重要的原则。

---

七、先创建专用 Linux 用户

设备服务不应该默认：

root

运行。

例如：

useradd \
    --system \
    --no-create-home \
    --shell /usr/sbin/nologin \
    device-web

得到：

device-web

系统用户。

然后程序运行：

User=device-web
Group=device-web

而不是：

User=root

---

八、为什么不要使用 root

如果 Web 应用存在漏洞：

HTTP
 ↓
Application Vulnerability
 ↓
Code Execution

如果进程本身就是：

root

攻击者可能直接获得：

root privilege

而普通用户：

device-web

至少增加了一层权限边界。

这就是：

Least Privilege

最小权限原则。

---

九、但设备程序经常需要访问硬件

例如：

/dev/ttyUSB0
/dev/i2c-1
/dev/gpiochip0

于是有人会直接：

那就 root 运行。

其实更合理的是：

给需要的设备权限

而不是：

给整个进程 root 权限。

例如通过：

Group
udev rules
device permissions

精确授权。

原则应该是：

需要什么权限
    ↓
授予什么权限

而不是：

为了省事
    ↓
root。

---

十、最简单的 systemd Service

建立：

/etc/systemd/system/device-web.service

内容：

[Unit]
Description=Device Web Service
After=network.target

[Service]
Type=simple
User=device-web
Group=device-web

WorkingDirectory=/opt/device-web

ExecStart=/opt/device-web/DeviceWeb

Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

这已经可以管理程序。

---

十一、三个 Section 分别是什么

systemd Service 文件通常：

[Unit]

[Service]

[Install]

三个部分。

---

十二、Unit

例如：

[Unit]
Description=Device Web Service
After=network.target

主要描述：

这个 Unit 是什么

与其他 Unit 的启动顺序关系是什么

例如：

After=network.target

表示：

device-web.service

在：

network.target

之后启动。

---

十三、注意：After 不等于 Depends On

这是 systemd 非常容易误解的地方。

After=network.target

主要表达：

Ordering

即：

启动顺序。

并不自动意味着：

没有 network.target
就绝对不能启动。

systemd 中：

Order

和：

Dependency

是两个概念。

这是理解 systemd 很重要的一点。

---

十四、Service

真正定义进程：

[Service]

Type=simple

User=device-web

Group=device-web

WorkingDirectory=/opt/device-web

ExecStart=/opt/device-web/DeviceWeb

最关键的是：

ExecStart

systemd 会启动：

/opt/device-web/DeviceWeb

---

十五、为什么 Native AOT 特别适合 ExecStart

因为 Native AOT 最终就是：

Linux Executable

所以：

ExecStart=/opt/device-web/DeviceWeb

非常自然。

不需要：

ExecStart=/usr/bin/dotnet /opt/device-web/DeviceWeb.dll

这也是 Native AOT 在设备部署方面非常舒服的一点。

---

十六、WorkingDirectory 为什么重要

假设程序内部：

File.ReadAllText(
    "config/default.json");

这是相对路径。

那么：

当前工作目录

会影响：

config/default.json

到底指向哪里。

设置：

WorkingDirectory=/opt/device-web

可以让进程的工作目录确定下来。

不过对于真正重要的持久化文件，我仍然更推荐：

明确绝对路径

或者通过配置生成绝对路径。

---

十七、ASP.NET Core 怎么设置监听地址

例如：

Environment=ASPNETCORE_URLS=http://0.0.0.0:8080

完整：

[Service]

Environment=ASPNETCORE_URLS=http://0.0.0.0:8080

ASP.NET Core 启动后：

Kestrel
 ↓
0.0.0.0:8080

也就是监听所有网络接口上的：

TCP 8080

---

十八、0.0.0.0 到底是什么意思

很多初学者容易把：

0.0.0.0

理解成设备 IP。

其实不是。

监听：

0.0.0.0:8080

表示：

在本机所有 IPv4 网络接口上接受连接。

例如设备有：

127.0.0.1

192.168.1.100

10.0.0.20

Kestrel 都可以接受相应接口：

:8080

上的连接。

---

十九、为什么不能只监听 localhost

如果：

http://127.0.0.1:8080

意味着：

只有设备本机

能够访问。

其他 PC：

Browser
   ↓
Ethernet
   ↓
Device

无法连接。

所以设备 Web 管理页面通常需要：

0.0.0.0

或者明确绑定某个设备接口地址。

---

二十、Environment 和 appsettings.json 谁负责什么

我比较推荐：

appsettings.json

保存：

Application Configuration

例如：

Polling Interval
Feature Settings
Application Options

systemd Environment：

Deployment Configuration

例如：

ASPNETCORE_URLS
DOTNET_ENVIRONMENT
特殊部署参数

这样：

应用逻辑配置

和：

部署环境配置

分开。

---

二十一、不要把大量配置全部塞进 service 文件

如果写成：

Environment=A=...
Environment=B=...
Environment=C=...
Environment=D=...
Environment=E=...
Environment=F=...

最终：

systemd service

会变成另一个配置中心。

更合理的是：

少量 Deployment Environment
+
Application Configuration File

职责清晰。

---

二十二、StateDirectory 非常适合设备程序

systemd 提供一个非常实用的配置：

StateDirectory=device-web

这样 systemd 可以管理：

/var/lib/device-web

这一类持久化状态目录。

Service：

[Service]

User=device-web
Group=device-web

StateDirectory=device-web

这样应用可以把持久化数据放：

/var/lib/device-web

---

二十三、这比程序自己 mkdir 更好

如果程序启动时：

Directory.CreateDirectory(
    "/var/lib/device-web");

但程序运行用户：

device-web

可能没有：

/var/lib

创建目录的权限。

于是你又开始：

root 创建目录
chown
chmod

而：

StateDirectory=device-web

可以让 systemd 在服务生命周期管理中处理相应目录。

部署结构更加规范。

---

二十四、一个更完整的 Service

例如：

[Unit]
Description=Device Web Service
After=network.target

[Service]
Type=simple

User=device-web
Group=device-web

WorkingDirectory=/opt/device-web

ExecStart=/opt/device-web/DeviceWeb

Environment=ASPNETCORE_URLS=http://0.0.0.0:8080

StateDirectory=device-web

Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

这已经比较接近实际设备服务。

---

二十五、启动 Service

修改 service 文件以后：

systemctl daemon-reload

然后：

systemctl start device-web.service

查看：

systemctl status device-web.service

---

二十六、为什么修改 service 后要 daemon-reload

systemd 不会因为：

/etc/systemd/system/device-web.service

文件发生变化，就自动重新解析所有 Unit。

所以：

systemctl daemon-reload

相当于告诉 systemd：

Unit 定义发生变化，请重新加载。

注意它不是：

restart application

只是：

Reload systemd configuration。

---

二十七、修改 Service 的标准流程

通常：

修改 .service
     ↓
systemctl daemon-reload
     ↓
systemctl restart device-web
     ↓
systemctl status device-web

这是非常常用的一套流程。

---

二十八、开机自动启动

执行：

systemctl enable device-web.service

这样设备下一次启动：

Boot
 ↓
systemd
 ↓
multi-user.target
 ↓
device-web.service

程序自动运行。

也可以：

systemctl enable --now device-web.service

同时：

Enable
+
Start

---

二十九、Install 的作用

例如：

[Install]
WantedBy=multi-user.target

主要影响：

systemctl enable

时建立的依赖关系。

简单理解：

multi-user.target
       ↓
device-web.service

从而进入正常多用户运行状态时：

启动 Device Web Service。

---

三十、systemctl status 能看什么

例如：

systemctl status device-web.service

可以看到：

Loaded
Active
Main PID
Memory
CPU
最近日志

如果：

Active: active (running)

说明：

进程还活着。

但这里有一个非常重要的区别。

---

三十一、Process Running 不等于 Application Healthy

例如 ASP.NET Core 进程：

PID 1234

仍然存在。

systemd：

active (running)

但是应用内部可能：

Device State = Error

这时候：

systemd

认为：

Process Healthy Enough

因为：

进程没有退出。

而业务系统认为：

Device Runtime Error。

这两个概念完全不同。

---

三十二、这是理解 Restart=on-failure 的关键

很多人配置：

Restart=on-failure

以后会认为：

应用进入 Error，systemd 会自动重启。

不会。

假设：

BackgroundService
   ↓
Device Error
   ↓
State = Error
   ↓
继续等待

此时：

ASP.NET Core Process

仍然：

Running。

所以 systemd 看到：

Exit Code?

没有。

进程根本没退出。

因此：

Restart=on-failure

不会触发。

---

三十三、Restart=on-failure 监控的是进程失败

例如：

Unhandled Exception
       ↓
Host Exit
       ↓
Process Exit Code != 0
       ↓
systemd
       ↓
Restart

这才是：

Restart=on-failure

的典型工作路径。

所以：

Business Error

和：

Process Failure

一定要区分。

---

三十四、推荐三层错误模型

可以理解成：

Level 1
Operational Failure

例如：
一次读取失败
一次网络超时

↓

Application 内部处理

第二层：

Level 2
Subsystem Failure

例如：
设备长期不可用
业务进入 Error

↓

State Machine / Recovery

第三层：

Level 3
Process Failure

例如：
程序内部不可恢复异常
Host 崩溃
关键 invariant 被破坏

↓

systemd

最终兜底。

---

三十五、不要让 systemd 代替应用状态机

例如一次设备查询失败：

Read Failed

不要立即：

Environment.Exit(1)

让 systemd：

Restart

否则：

一次普通业务错误

升级成：

整个应用重启。

可能导致：

Web 中断
状态丢失
资源重新初始化
服务抖动

systemd 应该是：

最后的进程级恢复层。

而不是：

第一层业务重试机制。

---

三十六、RestartSec 为什么重要

例如：

Restart=on-failure
RestartSec=5

如果进程：

启动
 ↓
立即崩溃

systemd 等：

5 秒

再启动。

否则可能：

Start
 ↓
Crash
 ↓
Start
 ↓
Crash
 ↓
Start
 ↓
Crash

形成高速：

Crash Loop。

---

三十七、但 RestartSec 还不是全部

真正生产环境还应该考虑：

StartLimitIntervalSec
StartLimitBurst

避免程序长期不断：

Crash → Restart

最终消耗：

CPU
日志
Flash
系统资源

设备软件尤其需要注意这种：

Restart Storm。

---

三十八、ASP.NET Core 怎么收到 systemctl stop

现在来看非常重要的一条链路。

执行：

systemctl stop device-web.service

systemd 会请求：

进程终止。

典型情况下 Linux 进程收到：

SIGTERM

然后：

systemd
   ↓
SIGTERM
   ↓
ASP.NET Core Host
   ↓
ApplicationStopping
   ↓
CancellationToken
   ↓
BackgroundService

---

三十九、这就是 stoppingToken 的来源

我们经常写：

protected override async Task ExecuteAsync(
    CancellationToken stoppingToken)

这个：

stoppingToken

并不是随便生成的 Token。

当 Host 开始关闭时：

Generic Host

会触发相应的停止流程。

于是：

stoppingToken.IsCancellationRequested

变成：

true。

---

四十、所以后台循环必须响应 Cancellation

正确：

while (
    !stoppingToken.IsCancellationRequested)
{
    await PollAsync(
        stoppingToken);

    await Task.Delay(
        1000,
        stoppingToken);
}

错误：

while (true)
{
    Poll();

    Thread.Sleep(1000);
}

第二种：

systemctl stop

以后可能无法快速结束。

---

四十一、Graceful Shutdown 完整链路

整个过程：

systemctl stop
      ↓
systemd
      ↓
SIGTERM
      ↓
ASP.NET Core Host
      ↓
ApplicationStopping
      ↓
Cancel stoppingToken
      ↓
BackgroundService stops
      ↓
Kestrel stops accepting requests
      ↓
Dispose resources
      ↓
Process Exit

这就是：

Graceful Shutdown。

---

四十二、为什么设备软件特别需要 Graceful Shutdown

设备程序可能持有：

File
Socket
Serial Port
Lock
Temporary File
Runtime State

如果直接：

SIGKILL

进程没有机会：

Flush
Close
Dispose
Save

所以正常：

systemctl stop
systemctl restart
设备关机

应该尽量走：

SIGTERM
+
Graceful Shutdown。

---

四十三、但不要把重要数据只留到 StopAsync 才保存

这是另一个非常重要的原则。

不要设计：

运行时一直修改配置
      ↓
只在 StopAsync 保存

因为：

断电
Kernel Panic
SIGKILL
进程 Crash

都可能：

没有 StopAsync。

真正重要的数据应该：

发生重要变化
    ↓
及时持久化。

Graceful Shutdown 只是：

正常退出优化

不是：

数据可靠性的唯一保障。

---

四十四、journald 和 ASP.NET Core 日志

ASP.NET Core 默认日志：

ILogger

最终通常写到：

Console

systemd 启动的进程：

stdout
stderr

可以由：

journald

收集。

因此：

ILogger<T>
   ↓
Console Logger
   ↓
stdout/stderr
   ↓
systemd
   ↓
journald

形成完整日志链。

---

四十五、查看日志

例如：

journalctl -u device-web.service

查看该 Service 日志。

实时：

journalctl -u device-web.service -f

相当于：

Follow

日志流。

---

四十六、只看本次启动

可以：

journalctl \
    -u device-web.service \
    -b

其中：

-b

表示当前：

Boot。

设备调试时非常有用。

---

四十七、查看最近日志

例如：

journalctl \
    -u device-web.service \
    -n 100

查看最近：

100 条。

这比直接：

cat application.log

更适合 systemd 服务。

---

四十八、为什么我更推荐 journald

设备端如果自己写：

app.log

马上会遇到：

日志文件越来越大怎么办？

Rotation 怎么做？

磁盘满怎么办？

多个进程怎么办？

时间戳怎么办？

服务启动批次怎么区分？

而 journald 已经提供：

统一日志
时间
Unit
PID
Boot
Priority
Rotation

等能力。

所以设备程序可以优先：

ILogger
 ↓
journald

而不是重新造一个完整日志系统。

---

四十九、但 journald 也不是无限空间

设备 Flash 通常有限。

所以必须考虑：

日志级别

例如：

Trace
Debug
Information
Warning
Error
Critical

不要把：

每秒正常轮询成功

写成：

Information。

否则：

24h × 高频循环

会产生大量无意义日志。

---

五十、一个合理的日志原则

正常稳定运行：

不记录
或 Debug

状态发生变化：

Information

可恢复异常：

Warning

操作失败：

Error

进程无法继续：

Critical

这样：

journalctl

看到的才是真正：

值得关注的信息。

---

五十一、ASP.NET Core 可以动态设置日志级别

例如：

Logging:LogLevel

可以：

{
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "DeviceWeb.Runtime": "Warning"
    }
  }
}

正常情况下：

Warning

减少日志。

调试时：

Debug

查看详细流程。

---

五十二、systemd 也可以覆盖配置

例如：

Environment=Logging__LogLevel__DeviceWeb.Runtime=Debug

ASP.NET Core Configuration 中：

__

可以映射：

:

于是：

Logging__LogLevel__DeviceWeb.Runtime

对应：

Logging:LogLevel:DeviceWeb.Runtime

这非常适合：

临时提高某个模块日志级别，而不修改应用默认配置。

---

五十三、但不要直接修改原 service 文件做临时调试

更推荐：

systemd drop-in

例如：

/etc/systemd/system/device-web.service.d/

下面创建：

debug.conf

内容：

[Service]
Environment=Logging__LogLevel__DeviceWeb.Runtime=Debug

然后：

systemctl daemon-reload
systemctl restart device-web.service

这样：

主 Service

保持稳定，

调试配置作为：

Override

存在。

---

五十四、为什么 Drop-in 很适合现场调试

正式配置：

device-web.service

不要随便改。

现场临时：

Debug Logging
特殊环境变量
实验参数

可以：

device-web.service.d/debug.conf

调试结束：

删除 drop-in
 ↓
daemon-reload
 ↓
restart

恢复正式行为。

这比：

现场直接改主 service

安全很多。

---

五十五、ExecStart 也可以被 Override

systemd 中覆盖：

ExecStart

需要注意：

它不是简单追加。

通常先：

ExecStart=

清空原来的值，

再：

ExecStart=/opt/device-web/DeviceWeb ...

例如：

[Service]

ExecStart=

ExecStart=/opt/device-web/DeviceWeb --SomeOption=Debug

这是 systemd drop-in 中非常常见的写法。

---

五十六、为什么这一点特别容易踩坑

如果直接：

[Service]
ExecStart=/opt/device-web/DeviceWeb --Debug

systemd 可能认为：

存在多个 ExecStart

而对应 Service 类型不允许这样的配置。

所以：

Override ExecStart

通常是：

Clear
 ↓
Set

即：

ExecStart=
ExecStart=...

---

五十七、如何确认 systemd 最终到底用了什么配置

非常推荐：

systemctl cat device-web.service

它可以帮助查看：

主 service
+
drop-in

从而知道：

最终有哪些配置参与。

调试 systemd 时非常实用。

---

五十八、Environment 和命令行参数谁优先

ASP.NET Core Configuration 通常可能来自：

appsettings.json

appsettings.Environment.json

Environment Variables

Command Line

不同 Provider 有优先级。

所以：

同一个 Key

可能被后加载的配置覆盖。

这也是为什么：

systemd Environment

非常适合部署覆盖。

而：

Command Line

适合更加临时和明确的启动覆盖。

---

五十九、systemd 和 ASP.NET Core 形成两套配置层

可以理解：

Application Defaults
        ↓
appsettings.json
        ↓
Environment
        ↓
Command Line

外面还有：

systemd

负责给：

Environment
Command Line

提供部署参数。

于是：

Application

不需要知道：

自己到底运行在哪台设备。

---

六十、升级应用时不要忘记停止 Service

一个比较安全的部署流程：

systemctl stop
      ↓
备份旧版本
      ↓
部署新 Binary
      ↓
设置 Owner / Permission
      ↓
systemctl start
      ↓
systemctl status
      ↓
journalctl

不要：

程序还在运行
      ↓
直接覆盖所有文件

尤其：

wwwroot
配置
Native Binary

同时更新时，

可能出现：

程序版本
≠
静态资源版本。

---

六十一、Native AOT Binary 要有执行权限

例如：

chmod +x \
    /opt/device-web/DeviceWeb

否则 systemd：

ExecStart

可能出现：

Permission denied。

这是新板部署很常见的问题。

---

六十二、还要注意架构

设备：

uname -m

如果返回：

aarch64

那么程序应该是：

ARM64

可以：

file \
    /opt/device-web/DeviceWeb

检查 ELF 信息。

如果误部署：

x86-64

到：

aarch64

设备上，

当然无法正常执行。

---

六十三、动态依赖也要检查

即使是 Native AOT：

Native

也不等于：

完全没有 Linux 动态库依赖。

可以：

ldd \
    /opt/device-web/DeviceWeb

查看运行时依赖。

例如可能涉及：

libc
libm
libpthread
libdl

具体情况取决于：

构建方式
目标平台
链接方式

所以：

Native AOT ≠ 一个与操作系统 ABI 完全无关的神秘单文件。

它仍然是：

Linux Native Program。

---

六十四、这也解释了为什么 sysroot 很重要

前面交叉编译文章中提到：

Linux x64 Build Host
      ↓
ARM64 Sysroot
      ↓
Native AOT
      ↓
ARM64 ELF

最终这个 ELF：

systemd
   ↓
exec

以后，

真正面对的是设备上的：

Linux Kernel
glibc
Dynamic Loader
Native Libraries

所以：

Build Environment

必须与：

Target Runtime ABI

兼容。

---

六十五、最终生产 Service 可以长什么样

例如：

[Unit]
Description=Device Web Service
After=network.target

[Service]
Type=simple

User=device-web
Group=device-web

WorkingDirectory=/opt/device-web

ExecStart=/opt/device-web/DeviceWeb

Environment=ASPNETCORE_URLS=http://0.0.0.0:8080

StateDirectory=device-web

Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

不要因为 systemd 有几十上百个选项，

一开始就把：

所有 Hardening Option
所有 Restart Option
所有 Resource Limit

全部塞进去。

原则还是：

先明确需求
 ↓
再增加配置。

---

六十六、整个系统现在完整了

我们终于可以把前几篇串起来。

编译阶段：

C#
 ↓
Roslyn
 ↓
Source Generator
 ↓
IL
 ↓
Native AOT
 ↓
ARM64 Native Code
 ↓
Linker
 ↓
ARM64 ELF

部署：

ARM64 ELF
 ↓
/opt/device-web

系统启动：

Linux Kernel
 ↓
systemd
 ↓
device-web.service
 ↓
Native ELF

应用启动：

ASP.NET Core Host
 ↓
Kestrel
 +
BackgroundService

运行：

Browser
   ↓
Minimal API
   ↓
Application
   ↓
Runtime State
   ↑
BackgroundService
   ↑
Infrastructure

日志：

ILogger
 ↓
Console
 ↓
stdout / stderr
 ↓
journald
 ↓
journalctl

停止：

systemctl stop
 ↓
SIGTERM
 ↓
ASP.NET Core Host
 ↓
CancellationToken
 ↓
BackgroundService Exit
 ↓
Dispose
 ↓
Process Exit

异常：

Process Crash
 ↓
systemd
 ↓
Restart=on-failure
 ↓
Process Restart

到这里：

ASP.NET Core
+
Native AOT
+
Linux
+
systemd

才真正组成了一套完整的设备运行架构。

---

总结

在 Linux ARM64 设备上部署 ASP.NET Core Native AOT 程序时，不应该只关注：

程序能不能运行。

真正需要设计的是：

程序由谁启动？

以什么用户运行？

数据放在哪里？

日志由谁管理？

怎么停止？

怎么重新启动？

进程崩溃怎么办？

业务错误怎么办？

设备重启怎么办？

怎么临时调试？

而 systemd 正好补齐了 ASP.NET Core 外部的：

Process Lifecycle

管理能力。

最终形成：

┌──────────────────────────────┐
│          Linux OS            │
│                              │
│          systemd             │
│              │               │
│              ▼               │
│     ASP.NET Core Process     │
│              │               │
│      ┌───────┴───────┐       │
│      ▼               ▼       │
│   Kestrel      Background    │
│                 Service      │
└──────────────────────────────┘

最重要的是理解职责：

业务错误
    ↓
Application

子系统恢复
    ↓
Runtime / State Machine

进程生命周期
    ↓
ASP.NET Core Host

进程崩溃恢复
    ↓
systemd

不要把这些层混在一起。

对于工业设备软件来说：

systemd 不是业务恢复机制，而是应用进程之外最后一道进程级监督机制。

这条边界一旦明确，很多：

Restart
Recovery
Error State
Graceful Shutdown
Logging

相关设计都会清晰很多。

---

下一篇

下一篇建议继续深入 Linux 部署底层：

《ASP.NET Core Native AOT 程序在 Linux 上到底是怎么启动的？从 ELF、glibc 到动态链接器》

前面我们已经知道：

systemd
 ↓
ExecStart
 ↓
DeviceWeb

但 Linux 到底怎么把这个 Native AOT 文件变成一个运行中的进程？

下一篇继续往下一层：

ELF Header 是什么？

file 命令到底看到了什么？

Program Header 是什么？

ldd 为什么能看到动态库？

glibc 到底是什么？

动态链接器 ld-linux-aarch64.so.1 做什么？

Native AOT 为什么仍然可能依赖 .so？

Kernel execve() 做了什么？

虚拟地址空间怎么建立？

.text / .rodata / .data / .bss 是什么？

程序的 Main() 到底什么时候开始执行？

systemd ExecStart 到 ASP.NET Core Main() 中间发生了什么？

把最后一条链彻底打通：

systemd
   ↓
execve()
   ↓
ELF
   ↓
Linux Loader
   ↓
Dynamic Linker
   ↓
glibc / Native Libraries
   ↓
Native AOT Runtime
   ↓
Main()
   ↓
CreateSlimBuilder()
   ↓
Kestrel

这篇会把前面的 Native AOT、sysroot、glibc、ARM64、systemd 真正连成一条完整链路。