系统应用

遇到 Win10 程序卡死、完全没反应时，通常就得直接把进程强制结束。常见做法有 3 种：①打开任务管理器（Ctrl+Shift+Esc）→进入“进程”页→找到“无响应”的项目→点击“结束任务”；②用命令行执行 taskkill /f /im 程序名.exe；③如果想连同进程树一起更彻底地清掉，可以

Win11出现蓝屏0x00000050，通常按这五步排查最有效：第一，先禁用或卸载远程控制软件、杀毒软件以及游戏反作弊驱动；第二，运行mdsched.exe做内存检测，再到事件查看器里核对结果；第三，执行sfc、DISM和chkdsk，分别修复系统文件与磁盘问题；第四，进入安全模式卸载那些顽固驱动；

退出码137表示进程被SIGKILL（信号9）强制终止，原因不限于OOM，还可能是手动kill、systemd终止或cgroup内存超限；需结合dmesg日志、OOMKilled标记及auditd审计综合定位真实源头。进程退出码 137 就是 SIGKILL，但不等于 OOM 很多人一看到 echo

定位响应时间波动需交叉比对四组指标：/proc/interrupts增量节奏、/proc/softirqs中NET_RX模式、mtr跳点StDev与Wrst、curl各阶段耗时，时间对齐后可精准归因中断瓶颈、队列溢出或网络拥塞。Linux 没有叫“响应波动归因表”的标准概念或文件，你真正想找的，是*

排查丢包时，先盯住/proc/net/dev里的Rx-DRP和Rx-OVR，通常就能把问题快速分层定位清楚：如果Rx-OVR>0，基本可以判断是Ring Buffer溢出，也就是硬件级丢包；如果Rx-DRP>0且Rx-OVR==0，那问题多半出在内核协议栈这一层。再往下，就配合ethtool -S去

如果想让 Ubuntu 在启动时把内核日志完整显示出来，不能只改一处。除了删除 /etc/default/grub 里的 quiet splash，还得把 /etc/grub.d/10_linux 中的 gfxmode $linux_gfx_mode 这一行一并去掉，然后执行 sudo update

要把 OpenSCAP 的 profile 和策略文件路径选准确，第一步得先确认策略文件确实在位，比如 /usr/share/xml/scap/ssg/content/ssg-rhel8-ds.xml。接着，再用 oscap info 把完整的 profile ID 查清楚，例如 xccdf_org

后台进程默认继承启动用户权限，不会自动提权或降权；常见权限问题源于用户本身无权操作（如绑定特权端口），而非后台机制导致。后台进程默认继承启动用户权限 在 Ubuntu 里，不管是用 &、nohup，还是 systemd 把进程放到后台，它都不会因为“转到后台”就自动提权，也不会莫名被降权。说白了，进

logrotate 的配置文件需要放到 /etc/logrotate.d/ 目录里，这一步不能放错。原因很直接：cron 实际上只会通过 /etc/cron.daily/logrotate 去调用 /etc/logrotate.conf，而后者又是靠 include /etc/logrotate.d

最常用且可靠的方法是使用 ls -l 命令，其输出第三列和第四列分别显示文件属主和属组；也可用 stat -c '%G' 精确提取属组名，或 stat -c '%g' 获取属组GID。ls -l 查看单个文件的所属用户组 直接用 ls -l 就能看清文件的属主和属组，这是最常用也最可靠的手段。 输出

MemTotal 是物理内存总容量的唯一可信基准，单位 KB，可从 /proc/meminfo 直接读取；free -h 显示的是内核实际管理的可用总量；dmidecode 反映硬件标称容量，但需 sudo 且不保证内核启用。直接看 MemTotal 字段，它就是物理内存总容量，单位是 KB，其他方

df -h定位满分区后，用ncdu -x交互扫描可快速精准找出磁盘空间占用元凶，比手动du高效准确；需注意挂载点、inode检查、删除确认及lsof验证句柄释放。磁盘快满了，直接跑 df -h 看哪块分区撑爆了，再用 ncdu 交互式扫描，比 du -sh /* 手动翻十遍快得多、准得多。 df -

查 GRUB2 实际安装版本应执行 grub2-editenv --version 或 grub2-mkconfig --version，输出如 2.02-102.el7；更可靠方式是 rpm -q grub2-common，直接显示包版本；UEFI 系统还需验证 shim-x64 与 grub2-

用 auditctl -w 监控目录时，如果发现子目录或目录内文件的操作没有被记录，原因其实很明确：-w 只会盯住目标路径本身的 inode，并不会递归追踪下面的子项。也就是说，像 -w /etc 这样的规则，只能捕获类似 chmod /etc 这类直接作用在目录自身的操作；至于 chmod /et

账户锁定策略由pam_faillock.so控制，CentOS 7默认推荐使用该模块；pam_tally2.so已被弃用，两者不可混用，否则导致策略失效或冲突。账户锁定策略由 pam_tally2.so 还是 pam_faillock.so 控制？ CentOS 7 默认推荐用 pam_faillo

在 Linux 环境里，想查 RAID 卡的缓存策略，不能只靠系统通用命令，还是得用厂商自己的工具才看得准。比如 MegaCLI，可以通过 -LDInfo -Lall -aALL 查看 Default/Current Cache Policy，其中会明确列出 WriteBack/WriteThrou

要判断系统版本，最稳妥的办法还是看/etc/os-release文件：它的结构足够清楚，字段也相对稳定，而且还是systemd广泛依赖的标准信息源。至于/etc/redhat-release，更适合人工快速扫一眼确认；hostnamectl在做综合排查时会更顺手；而rpm -q centos-rel

对已经在运行中的进程来说，renice算是最省事也最稳妥的优先级调整手段。普通用户通常只能把nice值调高，也就是让进程优先级往下降；只有root才有权限把nice值调低，甚至设成负值。它还支持按PID、按用户，或者按进程组进行批量修改。改完之后，最好再配合ps或top确认一下ni值有没有真正生效。

auditd服务未启动则规则无效，需手动启用并设为开机自启；规则文件须以.rules结尾，修改后执行augenrules --load加载；监控execve需指定架构并加-k标签；日志轮转需确保目录及文件权限正确。auditd服务没启动，加再多规则也没用 auditd默认不启用，装完包只是放了个二进

结论其实很明确：file -i最多只能做个大致判断，真要想更稳妥，还是得看enca -L zh（针对中文文件）或者直接用iconv -f XXX -t UTF-8手动试错；至于:set fileencoding，它显示的是 Vim 推测出来的编码，不是文件的真实编码，不能拿它当依据。直接看结论：**

必须将macOS系统语言设为简体中文并置顶，否则远程桌面软件无法显示中文界面；ToDesk需在偏好设置中手动选简体中文，向日葵和Apple远程桌面则完全依赖系统语言，必要时需清除偏好文件缓存。让Mac远程桌面软件显示中文界面，不是所有工具都支持手动切换语言，多数依赖系统级语言设置生效——必须先确保m

要确认是不是发生了 FD 泄漏，不能只看某一个瞬间，得用 watch -n 1 'ls /proc/PID/fd/ | wc -l' 持续盯着变化。要是这个数字一直比较稳定地往上走，比如 30 秒内增加了 20 个，那基本就该提高警惕了；再减去 3，才是实际打开的数量。接着配合 lsof -n -P

想直接拿到 /sys/class/hwmon 里的原始温度值，其实不复杂：先执行 cat /sys/class/hwmon/hwmon/name，找到名称里带 coretemp 或 k10temp 的目录；接着读取对应的 temp_input 文件。这里拿到的数值单位是毫摄氏度，最后再除以 1000