现代主流发行版中第一个用户空间进程是/sbin/init，但它是指向/lib/systemd/systemd的符号链接；init是传统概念，systemd是当前标准实现，负责服务管理、挂载、socket激活等。
linux 系统不是靠某个“核心程序”启动并维持运行的，而是由多个松耦合但职责明确的组件在内核调度下协同工作；理解它，关键不是背名词，而是看清 init 怎么交出控制权、systemd 如何接管服务生命周期、以及 /proc 和 /sys 这类伪文件系统怎么成为用户空间与内核交互的实时通道。
开机后第一个用户空间进程是谁？init 还是 systemd？
现代主流发行版（如 ubuntu 22.04+、centos 8+、Fedora）中，内核启动后执行的第一个用户空间进程是 /sbin/init，但它通常只是指向 systemd 的符号链接：
ls -l /sbin/init lrwxrwxrwx 1 root root 22 Jun 10 10:22 /sbin/init -> /lib/systemd/systemd这意味着：
-
init是传统概念，代表“系统初始化进程”，PID 恒为 1； -
systemd是当前事实标准实现，它不只是启动服务，还管理挂载点、socket 激活、cgroup 资源隔离、日志转发等； - 若你手动替换
/sbin/init为busybox init或sysvinit，系统会退回到传统启动流程，但多数新内核已默认禁用sysvinit兼容路径。
systemd 启动服务时，为什么有些服务没写 ExecStart= 也能跑？
因为 systemd 支持多种激活机制，不依赖轮询或固定命令行：
-
SocketActivated：服务由.socket单元监听端口（如sshd.socket），首次连接才拉起sshd.service； -
PathActivated：监控文件变化（如/var/log/messages新增日志）触发服务； -
TimerActivated：类似 cron，但基于高精度 monotonic 时间（如logrotate.timer）； - 部分服务甚至没有
ExecStart，只靠Type=notify+sd_notify(0, "READY=1")告知 systemd “我准备好了”。
查证方式：
systemctl cat sshd.socket systemctl show --property=TriggeredBy sshd.service /proc 和 /sys 都能看内核状态，区别在哪？
二者都是内存中的虚拟文件系统，但设计目标完全不同：
-
/proc主要暴露**进程和内核运行时快照**：比如/proc/1/cmdline是 PID 1 的启动命令，/proc/sys/net/ipv4/ip_forward控制 IP 转发开关； -
/sys是**设备与驱动模型的结构化视图**，强调层级和属性：比如/sys/class/net/eth0/operstate表示网卡当前操作状态，/sys/devices/virtual/tty/ttyS0/device指向其父设备； - 改动
/proc/sys/下参数等价于调用sysctl；而写/sys/下某些节点（如power/state）会直接触发内核行为（如休眠）； - 误写
/sys中只读节点会返回Invalid argument，而非权限拒绝——这是内核主动拦截，不是文件系统权限问题。
为什么 ps 看到的进程状态和 /proc/[pid]/stat 不一致？
因为 ps 显示的是采样时刻的**近似状态**，而 /proc/[pid]/stat 第三个字段（state）是内核任务结构体 task_struct->state 的原始值，含义更精确：
-
ps把S（可中断睡眠）、D（不可中断睡眠）都简标为S； -
/proc/[pid]/stat中D状态进程无法被信号中断（常见于磁盘 I/O 卡住），此时kill -9也无效； -
R+（ps输出）表示该进程在运行队列中等待 CPU，但未必正在执行；而/proc/[pid]/stat的R表示 kernel 正在调度它执行（极短暂）； - 想确认是否真卡死，优先看
/proc/[pid]/stack（需 root）或cat /proc/[pid]/status | grep State。
内核对进程状态的抽象比 shell 工具显示的精细得多，过度依赖 ps 容易误判阻塞类型。