企业官网建设流程全解析

1. 第二次作业，为什么比第一次更让人头大

如果你刚接触 Linux，第一次作业大概还在折腾“ls、cd、pwd”这几个命令，顶多再配个环境变量。但到了第二次作业，画风突然就变了——不再是单个命令的堆砌，而是命令、权限、进程、脚本、网络这些知识点搅在一起，像一锅看不清食材的大杂烩。我当年做 Linux 第二次作业时，光是理解“为什么明明命令敲对了，却还是 permission denied”就卡了整整一晚上。现在回头看，那次作业本质上考察的不是你会背多少命令，而是你有没有建立起“Linux 是一个多用户、多进程、由权限规则驱动的操作系统”这套底层认知。

这篇内容就是把我的第二次作业从“看懂题目”到“交上去还被老师挑出毛病”的全过程拆开揉碎，覆盖题目设计思路、常见命令的坑、Shell 脚本的套路、用户与权限的底层逻辑、进程管理的基本功，以及作业里最容易丢分的细节。无论你是还在挣扎的学生，还是刚转行准备补 Linux 基础的运维新人，照着这个思路走一遍，至少能少踩一半的坑。

2. 先搞懂作业背后到底在考什么

2.1 题目表象与真实意图的差距

大部分 Linux 第二次作业的题目长这样：“使用命令行完成用户的创建与删除、文件的权限修改、进程的查看与终止、编写一个简单的备份脚本。”字面上看，这就是四个独立的小任务，好像把命令背熟就能拿分。但等你真动手就会发现，里面每个任务都藏着连环坑。

• 创建用户，要涉及useradd、usermod、passwd，还要处理家目录、shell、UID 这些附加属性。
• 权限修改，不只是chmod 777完事，还牵扯到 rwx 对文件和目录的语义差异，以及umask对新建文件默认权限的影响。
• 查看进程，要区分ps和top的输出格式，要理解 PID、PPID、STAT 状态列的含义，终止进程时还要分清kill和pkill的适用场景。
• 写脚本，变量、条件判断、循环、crontab定时任务全可能加进来，语法错一处就整体跑不通。

所以第二次作业真正想让你学会的，是把 Linux 当成一个“有规矩的系统”去理解，而不是把命令当咒语去背。每个命令都有它作用的对象、依赖的环境、生效的条件，这三者任何一环不对，结果就和你预期的不一样。

2.2 一份典型作业的完整需求还原

以我当年那份作业为例，题目大概是这样的：

某公司新入职三名员工，需要为他们在服务器上创建账号，分别加入dev和ops两个用户组；要求新用户的家目录权限为 750，默认 Shell 为/bin/bash，密码由管理员统一初始化。完成后查看系统当前所有 bash 进程，找到占用内存最高的那个并结束它。最后编写一个脚本，实现每天凌晨 2 点把/var/log/nginx目录下最近 7 天修改过的.log文件压缩备份到/backup目录，并保留文件名中的日期信息。

这个题目典型到可以当模板用。拆开看，它考了四个知识点，但组合起来就是一次真实的 Linux 运维小场景：员工入职（用户管理）、安全检查（进程管理）、日志备份（脚本与定时任务）。很多人拿到题就去查单个命令，结果做完第一步就发现第二步连不上——因为用户能不能登录、能不能顺利执行脚本，全和你第一步的权限设置有关。

所以我的建议是：动手指前，先用纸笔把任务拆成依赖关系图。比如“备份脚本要能写/backup，那么当前用户对/backup有没有写权限？脚本执行时用什么身份跑？如果脚本里用了find，那find输出的文件名格式能不能直接拼到tar的参数里？”这些关系想不清楚，写代码就是瞎子摸象。

3. 用户与权限：第二次作业的分水岭

3.1 创建用户时的那些隐形参数

第一次作业里你可能只是切到 root 用户下敲了个useradd test，根本没注意这命令还带了一堆默认值。第二次作业想拿高分，你必须知道useradd背后做了什么。

在 CentOS/RHEL 系系统上，裸跑useradd zhangsan会生成一个新用户，但它的家目录、UID、GID、Shell 都是按/etc/default/useradd和/etc/login.defs里的默认值来的。我当年就在这上面栽过：useradd zhangsan之后，系统默认的家目录是/home/zhangsan，没问题；但如果你用useradd -M zhangsan指定不创建家目录，那这个人登录后连cd ~都会出错。第二次作业里题目明确要求“家目录权限为 750”，那你就得先确认家目录真的被创建出来了，并且还要改权限。

正确的创建流程应该是：

groupadd dev groupadd ops useradd -m -d /home/zhangsan -s /bin/bash -G dev zhangsan useradd -m -d /home/lisi -s /bin/bash -G ops lisi useradd -m -d /home/wangwu -s /bin/bash -G dev,ops wangwu

这里的-m表示如果家目录不存在则创建，-d指定家目录路径，-s指定登录 Shell，-G指定附加组。如果你想把某个组设为用户的初始组，用-g；如果只想让用户属于一个组，用-g就够，但题目要求附加组，所以用-G。

密码初始化这一步，最标准的是用管道配合chpasswd：

echo "zhangsan:InitialPass123" | chpasswd

chpasswd会批量读取用户名:密码格式的输入，比passwd zhangsan一条条敲效率高得多。但注意，这样的密码会出现在 shell 历史记录里，作业环境无所谓，生产环境务必禁止这种做法。

3.2 rwx 对文件和目录的语义完全不同

权限题里最常见的错误，是有人认为“文件能读就是能进目录”。我见过太多人把/home/zhangsan设成 777，问起来还一脸无辜：“老师不是说要让其他组的人能访问吗？”实际上，目录的权限三剑客 rwx 的含义是：

• 读（r）：可以列出目录下的文件名，也就是能执行ls。
• 写（w）：可以在目录里创建、删除、重命名文件，即能修改目录的内容。
• 执行（x）：可以进入该目录，也就是能cd进去，并且访问其中文件的具体属性。

关键来了：如果你只有目录的 r 权限，没有 x 权限，你可以看到目录里有a.txt这个名字，但你无法cat a.txt，因为系统需要先执行“查找这个文件”的过程，而这个过程需要目录的 x 权限。反过来，如果你只有 x 权限，没有 r 权限，你能进入目录，但如果知道文件名，依然可以直接打开文件——因为文件本身的权限是另一套判定标准。

所以题目里的“家目录权限为 750”，含义就是：属主（用户自己）可以进入并读写，属组（比如dev组）可以进入但只能读，其他人完全无法进入。这就保证了同组同事能查看你的工作目录，而外部人员被挡在外面。

修改权限时，我推荐你用这种显式写法：

chmod 750 /home/zhangsan chown zhangsan:dev /home/zhangsan

chown中的组必须是已存在的组，不然会报错“invalid group”。在脚本化批量操作时，可以先循环处理用户和组，再统一设权限，避免手误。

3.3 umask 引发的连锁反应

等你费尽心思把家目录改成 750，好消息是新创建的目录默认就会是 755，可你明明想继承家目录的 750。这是为什么？因为umask的默认值通常为 022，目录默认权限是 777 减去 umask，即 755；文件默认权限是 666 减去 umask，即 644。如果你想让新建目录自动是 750，那就得把umask改成 027。

作业里老师不会直接考umask的计算，但如果你在脚本里创建了一堆临时目录，然后备份时发现某些目录自己都读不了，那就是 umask 在捣鬼。解决办法有两个：一是脚本开头显式执行umask 027；二是用install -d -m 750这类命令，创建目录时直接指定权限。

3.4 删除用户时别忘了这些细节

有创建就有删除。题目如果还让你“删除一个离职员工账号”，你至少要知道三种删除方式的分寸：

userdel zhangsan # 只删除用户，不删家目录 userdel -r zhangsan # 删除用户连同家目录和邮件池 userdel -f zhangsan # 强制删除，即使该用户已登录

作业里如果题目没说要不要保留家目录，最稳妥的做法是先备份再删。我当时的做法是：

tar czf /backup/zhangsan_home_$(date +%F).tar.gz /home/zhangsan userdel -r zhangsan

这样既满足了题目要求，又让阅卷老师觉得你有生产环境的素养。

4. 进程管理：别把 kill -9 当万能药

4.1 用 ps 看懂系统里正在发生什么

第二次作业的进程部分，一般会让你“查看当前所有 bash 进程”或“找出 CPU/内存占用最高的进程”。第一步当然是ps，但ps的选项五花八门，最容易混淆。

• ps：只看当前终端下的进程。
• ps -ef：用标准格式列出所有进程，包含 PID、PPID、C、STIME、TIME、CMD 等列。
• ps aux：以 BSD 风格列出所有进程，包含 USER、PID、%CPU、%MEM、VSZ、RSS、TTY、STAT、START、TIME、COMMAND。

我推荐你直接记ps aux，因为%CPU和%MEM两列对于“找占用最高”的任务非常直观。不过ps aux输出里 COMMAND 列的进程名如果太长可能被截断，必要时用ps aux --sort=-%mem | head -10来按内存倒序排列。

如果题目要求“找出所有 bash 进程”，可以这么做：

ps aux | grep bash

但grep bash会把grep命令自身也匹配进去，因为命令行参数里包含“bash”字符串。这也是面试里常问的坑。解决方法是：

ps aux | grep bash | grep -v grep

或者用pgrep：

pgrep -l bash

pgrep的-l选项会同时输出 PID 和进程名，是替代 grep 管道的好东西。

4.2 读懂 STAT 状态列背后的含义

看到ps aux输出里的 STAT 列，很多人直接忽略，但第二次作业如果让你“解释某个进程的状态”，你就得知道：

• S：睡眠状态，可被信号唤醒，大多数等待 I/O 的进程都是 S。
• R：正在运行或可运行，这是最健康的状态。
• Z：僵尸进程，进程已终止但父进程没有回收它的退出状态。
• D：不可中断睡眠，通常在做磁盘 I/O，这种进程连kill都未必能立刻杀掉。
• T：停止，可能被 Ctrl+Z 挂起或用kill -STOP暂停。

额外字符如+表示前台进程组，s（小写）表示会话领导者。比如Ss就是“睡眠状态的会话领导者”，bash 解释器经常就是这个状态。

我在作业里写进程分析时，会特意挑一个Z状态的进程来说明“为什么它不会被 kill 掉”，因为这恰好能引出下面的知识点。

4.3 kill 的等级与使用时机

kill本质是向进程发送信号，默认信号是SIGTERM（15），它让进程有机会清理资源后优雅退出。如果你发现kill PID没用，再用kill -9 PID。-9是SIGKILL，内核直接强制终止进程，不给它任何善后机会，可能导致数据丢失或锁文件残留。

作业里“找到内存占用最高并结束它”的标准操作是：

ps aux --sort=-%mem | head -5

找到 PID 后执行：

kill PID

等待两秒，如果进程还在，用：

kill -9 PID

这里我要特别强调，写进作业报告里时，一定把“先尝试 SIGTERM 再使用 SIGKILL”这个流程写清楚。阅卷老师很看重你有没有这个意识，因为生产环境乱用kill -9是会出事故的。

顺便说一个排查技巧：如果你不确定 PID 对应的进程是什么，先执行ls -l /proc/PID看看进程的工作目录、打开的文件和启动命令，这个比ps的信息更详细。

ls -l /proc/1234/cwd ls -l /proc/1234/exe cat /proc/1234/cmdline | tr '\0' ' '

这些在作业里作为“加分项”写出来，会显得你是真的懂，而不是背命令。

5. 写脚本别只会“照模板抄”

5.1 备份脚本的框架与逐行拆解

第二次作业的脚本题大多是“备份类”“日志清理类”或者“批量创建用户类”。以我前面提到的备份脚本为例，先给一个完整可跑的版本：

#!/bin/bash # description: backup nginx logs modified in last 7 days SRC_DIR="/var/log/nginx" BACKUP_DIR="/backup" RETENTION_DAYS=7 DATE_TAG=$(date +%Y%m%d%H%M%S) # Ensure backup directory exists mkdir -p "${BACKUP_DIR}" # Find log files modified within 7 days FILES=$(find "${SRC_DIR}" -name "*.log" -mtime -7) if [ -z "${FILES}" ]; then echo "No files to backup." exit 0 fi tar -czf "${BACKUP_DIR}/nginx_logs_${DATE_TAG}.tar.gz" ${FILES} if [ $? -eq 0 ]; then echo "Backup succeeded: ${BACKUP_DIR}/nginx_logs_${DATE_TAG}.tar.gz" else echo "Backup failed." exit 1 fi

这段脚本里藏着几个关键点，也是作业里最容易丢分的地方：

• -mtime -7表示修改时间在 7 天以内（不含 7 天前的）。-mtime 7表示恰好 7 天前修改的，-mtime +7表示 7 天以前的。这个“加号、减号、无符号”的语义，几乎所有初学者都会搞混。我自己就因为在作业里写成-mtime 7，导致备份出来的文件里既有 7 天前的，又没有当天修改的，被老师专门标红。
• tar -czf中的z表示用 gzip 压缩，如果你备份的是大量文本日志，这个压缩率非常可观。
• ${FILES}如果不加引号，当文件路径中有空格时会被拆成多个参数，导致 tar 处理错误。但如果加了双引号，tar 又会把整个字符串当作一个文件名。所以这里有个取舍：当文件路径中没有空格时，用不带引号的${FILES}是安全的；为了保险，更推荐用find ... -print0配合tar --null -T -的写法，但作业里一般不需要搞那么复杂。
• $?是上一条命令的退出状态码，0 表示成功。这个变量在脚本里常用来做条件判断。

5.2 让脚本支持“今天没日志也不报错”

如果你直接运行上面的脚本，万一 nginx 目录里最近 7 天没有任何.log文件，find命令返回空字符串，tar就会因为缺少文件而报错。所以脚本里加了一个if [ -z "${FILES}" ]的判断，这是实用脚本和生产脚本的分界线。

-z表示字符串长度为 0。也可以用-n表示非空。很多新手会在 if 的判断条件里漏掉方括号前后的空格，写成if [-z "${FILES}"]，这是完全不行的，因为[是一个命令，它和后面的参数之间必须有空格。

5.3 定时任务配置中的身份与路径陷阱

脚本写完还不能算完，题目要求“每天凌晨 2 点执行”，这就得配crontab。正确的写法是：

crontab -e

然后在编辑器中写入：

0 2 * * * /usr/bin/bash /opt/scripts/backup_nginx.sh >> /var/log/backup_script.log 2>&1

这里最容易让人翻车的地方有三个。

第一个是 crond 服务的状态。很多精简版 Linux 镜像默认没装 cron，或者服务没启动。CentOS 上要确认一下：

systemctl status crond

如果没启，先：

systemctl enable --now crond

Debian/Ubuntu 上是cron，命令差不多。作业里如果没配置好服务，脚本永远不自动执行，但你自己看不到任何报错，这是最坑的。

第二个是环境变量问题。crontab执行脚本时，使用的 PATH 环境变量非常精简，可能不包含/usr/local/bin和/sbin。如果你的脚本里用了date、tar、find这些命令，它们通常都在/bin和/usr/bin里，问题不大；但如果你调用了自己安装的软件（比如 Python3.9 或者某个自定义工具），就必须在脚本开头加上绝对路径，或者显式 export PATH。稳妥做法是：

export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

第三个是权限问题。crontab -e为当前用户创建定时任务，如果当前用户是root，脚本就以 root 身份执行；如果你用一个普通用户去配置，脚本里对/backup目录的写权限就得单独确认。作业里往往要求用 root 操作，省事，但如果题目特意考察“最小权限”，你得会用sudo -u或其他方式切换身份。

5.4 脚本里的变量引用与引号规范

很多初学者写 Shell 脚本最大的毛病是“变量不加引号”和“该加引号时不加”。比如：

echo "备份目录是 $BACKUP_DIR"

这里如果用单引号，里面的$BACKUP_DIR就不会被解析成变量，而是输出字面量。作业里如果要求你打印“文件数量”，你可能会写：

echo "文件数量为 $(echo "$FILES" | wc -l)"

这个写法是可行的，但注意wc -l统计的是换行符数，如果FILES变量内部没有换行（比如它本身是一串空格分隔的路径），wc -l会输出 0，这不是你想要的。更稳的统计方式是先把 find 结果存到数组里，但 Bash 4 才支持mapfile。作业里一般用find ... | wc -l来数就够：

FILE_COUNT=$(find "${SRC_DIR}" -name "*.log" -mtime -7 | wc -l)

把这个值打印出来，作为脚本成功执行的旁证，阅卷老师会觉得很严谨。

6. 进程管理之外的常考组合：网络与日志

6.1 用 ss 还是 netstat？

很多第二次作业里会顺带考监听端口。比如“查看 nginx 是否在运行、端口是否监听”。老教程教你用netstat -tlnp，但新系统里netstat可能没装，或者提示让你用ss替代。原因很简单：ss由 iproute2 包提供，几乎所有现代发行版默认都有；netstat属于 net-tools，已经不再预装。

推荐命令：

ss -tlnp

• -t显示 TCP
• -l显示监听状态
• -n不解析主机名，直接用 IP 显示，速度快
• -p显示进程信息，需要 root 权限

这个命令的输出能直接告诉你哪个端口被哪个 PID 的哪个进程监听。我把这个知识点写进作业报告里“检查服务状态”的小节，是妥妥的加分项。

6.2 日志分析与文本处理三板斧

日志备份做完，作业里有时会让你“分析找到文件中出现 ERROR 的次数”。这时就要用grep、awk、sed。我的建议是别贪多，掌握三个场景就够了。

场景一，统计出现次数：

grep -c "ERROR" /var/log/nginx/error.log

场景二，按关键字筛选并只看后 20 行：

grep "ERROR" /var/log/nginx/error.log | tail -20

场景三，提取日志中的 IP 地址并按出现次数排序：

awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -10

这段命令里awk取第一列（Nginx access log 的第一列通常是客户端 IP），sort排序，uniq -c去重并计数，sort -nr按数字倒序，head -10取前十个。这是一条高频面试题，作业里能用上就直接写，显得基本功扎实。

6.3 提权与 sudo 的正确理解

热词里出现了“linux提权”，这个在第二次作业里也会以“修改用户权限”的形式出现，但注意，这指的是权限提升，不是渗透攻击。在作业场景里，你可能需要让普通用户临时拥有管理员权限，标准配置是sudo。

usermod -aG wheel zhangsan # CentOS/RHEL 上的管理员组

或者 Debian/Ubuntu 上：

usermod -aG sudo zhangsan

配置完成后，普通用户执行sudo -i就能切换到 root。但这里有个细节：usermod -aG中的-a表示追加，如果你忘了加-a，用户会被从原来的附加组中移除，只保留新组。这个坑极容易踩，特别是你在一条命令里想同时加多个组的时候。

还有，直接改/etc/sudoers时，千万别用普通编辑器乱改，应该用visudo命令，因为visudo会在保存时检查语法错误，避免你把自己锁在系统外。这是所有 Linux 老师都会强调的安全习惯，写进作业里显得很专业。

7. 常见问题与排查技巧实录

7.1 为什么新建用户无法登录？

现象：useradd创建用户后，su zhangsan切换，输入密码却报“authentication failure”。排查顺序如下：

• 先确认密码是否设置成功：passwd -S zhangsan查看密码状态。
• 再确认/etc/shadow中该用户是否存在：grep zhangsan /etc/shadow。
• 检查/etc/passwd中用户的 Shell 是否为可登录 Shell，如果 Shell 被设为/sbin/nologin或/bin/false，那就无法登录，这是系统故意禁止登录的。
• 最后检查家目录是否存在、属主是否正确：ls -ld /home/zhangsan。

我遇到过最离谱的情况是/etc/passwd里家目录路径写成/home/zhangsan/（多了一个末尾斜杠），导致有些工具无法正常解析，登录后当前目录变成/而不是家目录。这种隐蔽问题排查起来很耗时间，所以创建用户时尽量用系统默认路径，不要手改配置文件。

7.2 脚本执行报“Permission denied”到底是谁没权限？

如果你写完脚本后直接./backup_nginx.sh，系统报Permission denied，这不是脚本内容错误，而是脚本文件本身没有可执行权限。解决方法：

chmod +x backup_nginx.sh

另一种方式是直接用解释器运行：

bash backup_nginx.sh

这样不需要可执行权限，也是脚本调试期推荐的做法，因为你可以用bash -x backup_nginx.sh打印每条命令的执行过程：

bash -x backup_nginx.sh

-x是调试神器，会在每条命令前输出+前缀和你实际执行的命令。作业调试阶段，先把-x用起来，不要盲猜。脚本复杂的时候，我甚至会在关键位置加set -x和set +x，只在局部开启跟踪，避免整个输出刷屏。

7.3 crontab 不执行怎么办？

这是一道经典面试题，也是作业里的高频事故。排查步骤是：

1. 查看当前用户的 crontab 列表：crontab -l，确认真有这条规则。
2. 确认 crond 服务在运行：systemctl status crond。
3. 手动执行一遍脚本，确认脚本本身能成功。
4. 查看 cron 的日志，一般位于/var/log/cron，搜索你的脚本名或 PID。
5. 在 crontab 里把脚本输出重定向到文件，再等下一分钟验证。比如临时写一条* * * * * /usr/bin/bash /opt/scripts/test.sh >> /tmp/cron_debug.log 2>&1，如果一分钟后文件有内容，说明 cron 正常，问题出在脚本里的环境变量或路径上。

这里有个小技巧：cron 的最小粒度是一分钟，所以测试时要留出时间余量，不要看了个* * * * *就以为会立刻执行。

7.4 chmod 的数字怎么算才对？

权限数字的算法是 r=4、w=2、x=1，然后每组权限相加。750 代表属主为 7（4+2+1，rwx），属组为 5（4+1，r-x），其他人为 0（无权限）。如果你算出来不一样，那就是二进制转换错了。为了不在作业里出低级错误，建议在命令行先用stat -c "%a %n" /home/zhangsan查看实际权限位，再和你的预期值对比。生产环境里一条错误的chmod -R 777 /足以毁掉整个系统，所以数字权限务必想清楚再执行。

8. 一次完整的作业逐坑实操演示

为了让前面这些零散知识串起来，下面模拟一遍完整作业操作流程，从空服务器开始，一步一步做到可交付。

环境准备：我用的是一台 CentOS 7.9 虚拟机，root 登录，已配置好网络和 yum 源。如果你用的是 Ubuntu，把安装命令换成apt，其余原理一致。

第一步，创建用户组和用户：

groupadd dev groupadd ops useradd -m -d /home/zhangsan -s /bin/bash -G dev zhangsan useradd -m -d /home/lisi -s /bin/bash -G ops lisi useradd -m -d /home/wangwu -s /bin/bash -G dev,ops wangwu echo "zhangsan:Passw0rd1" | chpasswd echo "lisi:Passw0rd2" | chpasswd echo "wangwu:Passw0rd3" | chpasswd

第二步，设置家目录权限并调整属主属组：

chmod 750 /home/zhangsan /home/lisi /home/wangwu chown zhangsan:dev /home/zhangsan chown lisi:ops /home/lisi chown wangwu:dev /home/wangwu

这里注意chown wangwu:dev只是把属组改成 dev，但 wangwu 依然在 ops 组里，这是符合题目要求的。

第三步，验证用户与权限：

id zhangsan ls -ld /home/zhangsan

id zhangsan会输出 uid、gid 和所有附加组，一眼就能看到 dev 是否生效。

第四步，模拟 nginx 日志环境并准备脚本：

mkdir -p /var/log/nginx touch /var/log/nginx/access.log /var/log/nginx/error.log echo "test error" >> /var/log/nginx/error.log

用简单的 touch 和 echo 造出日志文件，保证find能查出内容。然后编写脚本：

mkdir -p /opt/scripts vim /opt/scripts/backup_nginx.sh

脚本内容就是上一节的那个版本。写完后执行调试：

bash /opt/scripts/backup_nginx.sh

如果输出Backup succeeded，再检查备份包：

tar -tzf /backup/nginx_logs_*.tar.gz | head

tar -tzf可以不解压直接查看压缩包内容列表，验证是否把日志文件打进去了。

第五步，配置 cron：

crontab -e

加入：

0 2 * * * /usr/bin/bash /opt/scripts/backup_nginx.sh >> /var/log/backup_nginx.log 2>&1

然后立即检查：

crontab -l systemctl status crond

第六步，进程管理部分。先找出所有 bash 进程：

ps aux | grep bash | grep -v grep

假设输出的第二个进程 PID 是 4567，内存占用 2.1%，那我们可以按内存排序确认：

ps aux --sort=-%mem | head -5

如果确认 4567 就是目标进程，执行：

kill 4567 sleep 2 ps -p 4567

ps -p 4567如果输出空，说明进程已经终止。如果还在，再执行kill -9 4567。

第七步，把所有操作过程和截图整理成报告，重点标注出关键命令的说明，以及你踩过的坑。我记得我当时的报告里专门写了一小节“umask 对新建目录权限的影响”，因为这个细节大多数同学都没发现，成了整个作业的亮点。

9. 检查清单与交付前自测

作业做完不等于能交，我还总结了一份检查清单，每次交付前按这个过一遍，能挡住 90% 的低级失误：

• 用户方面：useradd是否带了-m？家目录是否创建？属主属组对不对？附加组用-aG而不是-G？密码是否设置成功？
• 权限方面：家目录权限是不是 750？文件权限和目录权限的语义是否区分开？chown的组名是否存在？
• 脚本方面：脚本有没有可执行权限（如果直接执行）？变量有没有加引号？find的-mtime加号减号是否正确？tar解压验证过没有？
• cron 方面：crond 服务是否在运行？脚本路径是否绝对路径？输出有没有重定向到日志？
• 进程方面：是否先尝试SIGTERM再用SIGKILL？是否能解释进程状态列的含义？
• 日志方面：备份的产物文件名是否含日期？清单内容是否可读？

把这些点都打上勾，你的第二次作业基本就是优秀档了。

以我个人经验，第二次作业的意义不在于那一份分数，而在于它逼着你第一次用“系统管理员”的视角去看 Linux。当你不再把命令当孤立咒语，而是开始理解用户、权限、进程、定时任务这些部件如何咬合在一起时，后续学网络、学服务部署、学容器，都会有顺滑很多的感觉。第一次被权限拒绝不要急，第一次脚本跑不出来也不要慌，这些坑我全踩过，踩完你就记住了。最后再多说一句，调试脚本时永远留一份命令记录，不管是用history还是终端日志，回头复盘的时候，那些“当初我怎么就没想到”的瞬间，其实全藏在记录里。