Linux入门第三天：用户权限、进程管理与网络排查实战复盘

记不清具体是从哪个早晨开始的，反正当我照例打开虚拟机敲下那串熟悉命令时，突然意识到学 Linux 已经进入第三天了。前两天基本在折腾安装、熟悉目录结构、练习文件操作，tar、grep、vim 这些命令也算能上手。但真正让我觉得“自己好像开始懂 Linux”的，恰恰是第三天学的内容——用户与权限、进程管理、基础网络排查。因为从这天起，操作对象不再只是“文件”这一个抽象概念，而是整个系统在如何运转、如何被管理。这篇文章就完整复盘我第三天的学习路线、实操命令和踩过的坑，给同样卡在入门阶段的你一个参考。

1. 先盘一盘：前两天打了什么底子，第三天该啃哪块硬骨头

1.1 我的前两天下班式学习路线

第一天的内容很简单，就是两件事：把 Linux 装上，把目录结构看明白。我选的是虚拟机安装 Ubuntu 桌面版，图形界面方便初期排查问题，但所有操作尽量都在终端里完成。这一天从/根目录开始逛：/etc放配置、/var放日志、/home放用户数据、/tmp放临时文件，然后反复练习pwd、ls、cd、mkdir、cp、mv、rm这些最基本的文件操作。当时的感受是：这不就是个没有回收站的 Windows 吗？有什么难的。

第二天的内容往上走了一层，从“能不能找到文件”变成“能不能读懂文件”。cat、tail -f、head、less看文件，grep过滤关键行，cut和sort做简单文本处理，再用 vim 改了几个配置文件。这一天最有价值的收获，是理解了 Linux 的设计哲学：一切皆文件，而文本是万能的接口。日志、配置、运行状态，全是文本，命令行只是把这些文本打开给你看而已。

1.2 第三天到底在学什么

如果说前两天的关键词是“文件”，那第三天的关键词就是“系统”。我从“我能操作文件”过渡到“我能管理一台机器的运行状态”。按紧急程度排，需要过三关：

这四块是后面学 Everything-as-a-Service、部署应用、排查故障的底层能力。我当时不知道这些概念有多重要，只觉得“权限这两个字怎么这么难”，但硬啃完三天后，再回去看那些报错，才真正意识到前两天的自己根本不知道自己在做什么。

2. 用户和组：多用户系统到底在防什么

2.1 先想明白用户和组解决什么问题

一台 Linux 服务器从来不是只给一个人用的。线上服务器上可能有 nginx 用户跑 Web、mysql 用户跑数据库、root 做运维、普通开发人员做应用发布。如果所有人和程序都用 root 身份干所有事，那一个手滑的rm -rf可能把整台机器废掉。

用户和组就是用来划清边界的。用个生活化类比：root 是房东，手里有全局钥匙；普通用户是租客，只能进自己的房间；组是合租群组，比如“运维组”这一群人共享一个柜子的钥匙。组的意义在于：你不需要挨个给 20 个人设置权限，只需把这 20 个人拉进同一个组，再设置组的权限就行。

2.2 实操：新建用户、设置密码、加入组

我第三天第一件事就是练习创建用户。命令不复杂：

sudo useradd -m -s /bin/bash dev1 sudo passwd dev1

-m表示同时创建家目录/home/dev1，-s /bin/bash指定登录 shell。这里特别容易犯的错是少写-m，结果用户建好了，但/home下没有对应目录，登录后连家目录都没有，很多操作会报错。

创建完用id dev1查看用户信息，会看到 uid、gid 和所属组列表。再看一眼/etc/passwd中的那一行，字段依次是用户名、密码占位符、UID、GID、描述信息、家目录、登录 shell。这个文件权限对所有人可读，但真正的密码哈希放在/etc/shadow里，只有 root 能读，所以不要把密码直接放在/etc/passwd里。

我接着练习创建组、把用户加进组里：

sudo groupadd devteam sudo usermod -aG devteam dev1

注意-aG里的-a是 append，追加的意思。如果写成sudo usermod -G devteam dev1而没有-a，会把用户从原来所属的附加组里全部踢出来，只保留这一个组。这个坑我在后面加用户时踩过，线上环境里千万别这么干。

2.3 删除用户也不能掉以轻心

第三天我还特意练了反向操作，删用户：

sudo userdel -r dev1

这里的关键是-r，删除用户的同时把家目录和 mail spool 一起清掉。我第一次没加-r删了一个测试用户，后来发现/home/dev1整个目录还孤零零躺在那里，里面残留一堆缓存和配置文件。下一次再创建同名用户时，这个目录就会变成“历史遗留”，既影响权限设置，也容易让配置文件互相干扰。

2.4 su、sudo 与身份切换的心理建设

入门阶段我对su和sudo的理解一直糊成一团，第三天总算理清了。su是切换用户，比如su - dev1，需要输入 dev1 的密码；sudo是用你自己的密码，以 root 身份来执行某一条命令。前者是“变成别人”，后者是“借用一下权限”。

日常操作务必养成一个习惯：能用sudo精确到单条命令，就不要直接su - root切到 root 身份。因为一旦进入 root 的交互式 shell，你的每一次误操作都没有后悔药。我这里不是说 sudo 不会误删，而是至少你能保证误操作范围是“当前这一条命令”，而不是整段 root 会话。

给用户 sudo 权限的方法也很直接：

sudo usermod -aG sudo dev1

Ubuntu 上把用户加进sudo组即可，CentOS/RHEL 上是wheel组。不同发行版组名不一样，这是刚开始容易懵的地方。修改完，让 dev1 重新登录后执行sudo -i测试一下。

3. 文件权限：rwx 只是三个字母，背后却是一套安全模型

3.1 从 ls -l 里读懂权限结构

前两天的ls -l我只看了文件大小和修改时间，第三天开始认真研究这一长串内容到底在说什么。拿一条输出举例：

drwxr-xr-x 2 dev1 devteam 4096 10月 10 10:00 project

第一位的d表示这是个目录，普通文件是-。后面九个字符分成三组：rwx、r-x、r-x，分别对应文件所有者（u）、所属组（g）、其他人（o）。目录的 x 权限不是“执行”，而是“能不能进入这个目录”；目录的 r 权限是“能不能列出目录里的内容”。所以一个目录如果你只能进不能读，那ls是列不出内容的，如果只有读权限没有执行权限，那目录只能看不能进。

文件的 rwx 就更直观：r 是能读内容，w 是能修改内容，x 是能作为程序运行。组合起来就是三种身份的权限分别是什么。

3.2 chmod 数字表示法，为什么是 754

数字表示法本质上是把 rwx 当成二进制位来看：r = 4、w = 2、x = 1。三者相加即可，7 = rwx、6 = rw-、5 = r-x、4 = r--。

举个最常见的组合：

所以chmod 754表示所有者 rwx、组 r-x、其他人 r--。我一开始总记不住 4、2、1 是哪来的，后来直接背“读4写2执行1”，用多了自然就顺手了。如果是递归修改目录里所有文件，要加-R：

sudo chmod -R 755 /srv/project

3.3 chown 换主人，不是随便换的

权限的设置对象是“哪个用户、哪个组”，所以改权限时经常也要改所有者。命令格式：

sudo chown dev1:devteam /srv/project

dev1:devteam意思是所有者为 dev1，所属组为 devteam。只改组可以单独用chgrp devteam project，但我一般都直接一条chown搞定。

常见场景是：你想让一个用户负责某个项目目录，比如把/srv/project整个“交给” dev1，那必须chown -R dev1:devteam /srv/project，否则 dev1 虽然能读，但没有写权限，改不了文件。这个细节在部署应用时特别容易踩坑，尤其是把代码从 root 账号拷贝到普通用户目录时，所有权全是 root，导致普通用户启动的服务半天没有写权限。

3.4 umask：新文件权限的幕后控制者

你有没有好奇过：为什么我新建出来的文件默认是644，新建的目录默认是755，而不是777？答案就是 umask。

umask 是一个“默认权限掩码”。计算方式可以简单理解成：文件默认 666 减去 umask 值，目录默认 777 减去 umask 值，但文件的计算结果里还要去掉执行位，因为普通文件默认不会带 x。大多数发行版的默认 umask 是 022，所以：

• 文件：666 - 022 = 644
• 目录：777 - 022 = 755

用umask命令可以查看，用umask 027可以临时改。如果你想设置“只有自己能读写、组内能读、其他人什么都干不了”，可以设成 027，这样新文件出来是 640、新目录是 750。这个对共享目录很重要：如果 umask 太宽松（比如 000），新文件是 666，意味着任何人都能改，非常危险；太严格（比如 077），共享目录里别人创建的文件你连看都看不到。

3.5 特殊权限位：SUID、SGID、粘滞位

基础权限之上还有三个特殊位，我第三天只做了初步了解，但必须知道它们的存在。

粘滞位最典型的是/tmp目录。你用一个 Linux 服务器，大家都能在/tmp下建临时文件，但不能随便删别人建的文件。这就是chmod +t /tmp的效果，目录权限显示为drwxrwxrwt，最后的t就是粘滞位。

SUID 是“运行时临时拥有所有者的权限”。经典例子是/usr/bin/passwd：普通用户要改自己的密码，必然要写/etc/shadow，而这个文件只有 root 能写。于是 passwd 程序设置了 SUID，运行时就以 root 身份操作文件。查看时可见-rwsr-xr-x，所有者执行位变成s。但要注意，给一个不该有 SUID 的程序加上 SUID，等于让任何人都能以高权限运行它，这是很大的安全隐患。新手阶段看到不认识的 SUID 文件不要乱动，更不要自己到处加。

SGID 类似，主要应用场景是共享目录：给目录设置chmod g+s，那么在这个目录里新建的文件会自动继承目录的所属组，而不是创建者自己的组。多人协作的项目目录靠这个避免“文件建出来别人没权限”的问题。

4. 进程管理：从“看得见”到“管得住”

4.1 什么是进程，为什么要管它

程序是一堆躺在磁盘上的代码，运行起来之后的“活体”叫进程。第二天我们处理的是静态文件，第三天开始面对的是动态的运行实体。一台机器同时跑着上百个进程，哪个占 CPU、哪个占内存、哪个服务挂了，你都得有能力快速定位。

4.2 ps：快照式查看当前状态

查看进程最常用的组合是ps aux，虽然选项长得像英文单词，但其实这里a表示所有用户、u表示显示用户和资源占用、x表示包含没有终端的进程。输出里有 PID、CPU%、MEM%、STAT（状态）、COMMAND（命令行）等列。我最常用的操作是配合 grep 过滤：

ps aux | grep nginx

这里有个坑：grep本身也会出现在结果里，因为你 grep 的命令行里包含“nginx”这四个字符。处理办法是加一个过滤，或者用pgrep：

ps aux | grep nginx | grep -v grep pgrep -a nginx

入门时我每次看到结果里多一行 grep 都懵半天，后来才明白是自己在匹配自己。

4.3 top：实时看资源占用

ps是个快照，top则是动态刷新。进入top后按P可以按 CPU 排序，按M按内存排序，按q退出。很多新手进去以后退不出来，只能关终端，其实一个q就解决了。

top上半部分是系统负载、进程数、CPU 和内存概况，下半部分是一个动态进程列表。当时我一个个字段去对，发现最值得关注的其实就三块：load average 是否超过 CPU 核数、内存里的 available 是否偏少、以及排在 CPU 占用率前几位的进程到底是谁。真到排查线上问题时，top往往是我敲的第一条命令。

4.4 后台运行与 nohup：关掉终端进程不能死

我第三天的练习里有一个很实用的场景：启动一个长时间运行的脚本，但我不想一直占着终端。最基础的做法是命令末尾加&：

./test.sh &

执行后系统会返回一个 PID，把进程放到后台。用jobs可以查看当前终端的后台任务，fg把任务调回前台，bg让暂停的任务在后台继续。

不过如果直接关闭终端，后台进程一般会被 SIGHUP 信号杀掉。想让它在你退出登录后继续跑，就得用nohup：

nohup ./test.sh > test.log 2>&1 &

这里> test.log把标准输出写到日志文件，2>&1表示把标准错误也重定向到同一个地方。不写这段，错误信息会跑到 nohup.out 里，日志不好找。我第一次跑脚本时没加输出重定向，结果一屏幕日志直接刷没了，找半天才看到 nohup.out 文件。

4.5 kill 与信号：别一上来就 kill -9

管理进程除了看和放后台，还要会“结束”。kill PID默认发送 SIGTERM（信号 15），这是“请求进程自己退出”，给它机会保存数据、清理现场。很多新手出了问题直接kill -9，把 SIGKILL（信号 9）拉出来，强力杀死进程。这确实能杀掉大部分进程，但代价是没有任何清理机会，可能造成文件损坏、数据丢失。

我的原则是：先kill PID，等几秒看进程退没退；退不了再用kill -9 PID。信号列表可以用kill -l查看，但我日常真正用得上的也就 15 和 9 两个。按名字批量结束进程可以用killall nginx，但确认名字别打错，否则可能误杀。

4.6 systemd 基础：服务是怎么被拉起的

进程管理最终要落到服务身上。部署 nginx、mysql 这类应用，不会直接跑二进制命令，而是交给 systemd 管理：

systemctl status nginx sudo systemctl start nginx sudo systemctl enable nginx

status看运行状态，start/stop/restart控制启停，enable设置开机自启，disable取消开自启。理解 systemd 的时候，把它当成整个系统的“大管家”：开机时拉起各种服务，服务挂掉后按配置拉起或报警。前面学的ps aux，会看到 PID 1 就是 systemd，所有进程最终都要看它的脸色。

5. 系统和网络排查：第三天最实用的“体检组合”

5.1 先学会看这台机器“活没活”

第三天我学的最后一块内容，是给机器做“体检”。第一件事是看 IP：

ip addr

这个命令列出所有网卡和 IP 地址，重点看eth0或ens33这类实际网卡下面的inet行。想查看默认网关用ip route。网络通不通，最直接的是ping：

ping -c 4 8.8.8.8

注意-c 4是只发 4 个包，不然ping会一直跑下去，新手按 Ctrl+C 才能停。如果ping不通，基本是网络层问题；如果ping通但访问不了服务，问题一般出在服务端口或防火墙，别混为一谈。

5.2 端口监听：ss 一个命令顶一串

一台机器上有 Web 服务、数据库服务、各种内部工具，端口是最直观的入口。查看当前端口监听情况：

ss -tlnp

-t只看 TCP，-l只看处于监听状态的端口，-n用数字显示地址和端口，-p显示对应进程。合起来就是“这台机器现在到底在对外提供哪些服务”。当我想知道某个端口被谁占用了，可以：

ss -tlnp | grep 8080

在部署 Spring Boot 这类应用时，最常见的报错就是“端口被占用”，这一条命令能让你迅速找到罪魁祸首，提高排查效率。

5.3 磁盘和内存：df、du、free

磁盘满是最常见的线上事故原因。df -h查看各分区使用率：

df -h

如果根分区Use%到了 100%，服务很容易起不来，日志也写不进去，表现出的现象可能是“所有服务都不正常”。《/》 满了之后，连 CPU 和内存都看不出问题，但机器就是莫名其妙出故障。

定位谁占的磁盘用du：

du -sh /var/log/*

-s汇总每个目录大小，-h可读性显示。排查时我一般从根上往下逐层看，比如先du -sh /var/*，看到/var/log巨大，再钻进/var/log里看具体哪个日志文件。内存状态用free -h：

free -h

mem里的available是真正可用的内存，swap使用率如果明显上升，往往说明物理内存已经吃紧了。服务器出现卡顿的时候，先看free能排除一半问题。

5.4 日志：最后一步才看，但必须知道去哪看

前面几步还查不出问题时，就得看日志了。系统内核日志用：

dmesg | tail -n 30

看最近的内核信息，比如网卡掉线、磁盘 I/O 错误、硬件问题都会在这里。服务日志用journalctl：

journalctl -u nginx --since today

只看某个服务今天的日志。注意 if 上去后报错无非三种：配置文件写错、端口被占、磁盘满。大概率顺序一定是：df -h→free -h→ss -tlnp→ 日志。按这个顺序排查，效率高很多。

6. 综合练习：把第三天的知识点串成一条线

6.1 我给自己设计的一套可复现练习题

第三天快结束时，我给自己安排了一个综合练习，把这四块知识全部串起来。你不妨照做一遍：

# 1. 创建组和用户 sudo groupadd devteam sudo useradd -m -s /bin/bash dev1 sudo useradd -m -s /bin/bash dev2 sudo useradd -m -s /bin/bash dev3 # 2. 设置密码 sudo passwd dev1 # 3. 把 dev1、dev2 加入 devteam，把 dev1 加入 sudo 组 sudo usermod -aG devteam dev1 sudo usermod -aG devteam dev2 sudo usermod -aG sudo dev1 # 4. 创建共享目录，权限 775 sudo mkdir -p /srv/project sudo chown dev1:devteam /srv/project sudo chmod 775 /srv/project # 5. 用 dev2 在共享目录里创建文件，测试组内可写 # sudo -u dev2 touch /srv/project/test.txt # 6. 访问控制验证：在 /srv/project 下创建一个只让组操作的文件 sudo touch /srv/project/internal.txt sudo chown dev1:devteam /srv/project/internal.txt sudo chmod 660 /srv/project/internal.txt

完成后的预期结果：dev2 能在/srv/project里正常创建和修改文件；dev3 因为不在 devteam 组，权限位 775 下只有“其他人”的读和执行权限，能看见目录但写不了；internal.txt 设置了 660，dev3 连读都读不了。这一步做完，基本就把用户、组、权限、目录设计打通了。

6.2 实操中踩过的一些坑

第一个坑是创建用户时忘了-m，导致没有家目录，登录后一堆操作在/下进行，各种权限错误。第二次我直接把useradd的所有参数都补齐，避免半路填坑。

第二个坑是usermod加组时漏了-a。当时只写了sudo usermod -G devteam dev1，结果 dev1 被打回原形，原来的附加组全被清了。从那以后，我的习惯是先id dev1看一下当前组结构，再加组。

第三个坑是 chmod 777 用顺手之后，以为万事大吉，结果测试时发现 dev3 也能改文件了，共享目录的隔离失效。导师当时提醒我：“777 一时爽，权限火葬场。”后来我再给共享目录设权限，都先明确需求：谁要读写、组内谁要读写、其他人到底有没有必要看。

第四个坑是进程排查时用kill -9杀掉了 sshd 相关进程，差点把自己 SSH 会话直接断掉。教训是：kill之前先看 PID 对应的进程名，别只看 PID 就动手。

6.3 第三天之后，往下怎么走

第三天结束以后，我给自己排了个后续计划：先练 vim 进阶和 shell 脚本，因为脚本本质上就是把命令串起来，权限、进程、网络命令练熟了，脚本才有用武之地。然后学软件包管理，apt/yum 装包卸包，再学防火墙基础，ufw/firewalld 的概念和用法。最后是 SSH 远程登录与密钥配置，从“本机操作”跨到“远程运维”。

到最后一天你会发现，之前学的所有命令都在为一个目标服务：在一台你看不见的主机上，安全、高效地完成各种操作。用户和权限是安全的前提，进程管理是稳定的关键，网络排查是故障的出口，这几块永远是 Linux 运维的核心底座。

最后分享一个我在第三天的真实体会：最容易让人放弃 Linux 的时刻，不是遇到报错，而是“不知道自己在干什么”。每天学完别急着关机，花半小时把当天命令从头到尾“表演”一遍，哪怕只是照抄一遍笔记，都会让记忆牢固很多。我后来把每天的命令整理成 Markdown 笔记，滚动复习，第三天的知识到现在还在用。Linux 入门没有捷径，但把“用户、权限、进程、网络”这四件事吃透，后面再看什么文档都顺眼很多。