建议 Xubuntu 18.04
个人感觉 Xfce 比 Gnome/Unity(Ubuntu 16.04-)占用资源都少

1s

@meloner 不按规范成了沟通问题？

鲁棒性那是考虑用户 /合作方错误操作 /输入错误数据。
不是考虑自己一方违反规范

价格屠夫
超售大王

石头盘
奇葩 TOS
记得重装系统还收费

@AllOfMe 不是我做的，是他们的开发搞的。

他们的开发好多测试直接在生产环境做(这就是我为什么说他们是垃圾公司)

要用一个(只)兼容旧版本 libc 的程序(好像是 RHEL 4 时代的)，于是开发便不管不顾

不用容器(虚拟机 /docker)
不静态编译(libc.a)
不用 rpath 指定运行时 libc.so 的 path

就想到换掉系统的 libc.so.6

最后没重装，恢复模式下把安装介质上的 libc.so.6 拷回去并重建了 symlink，重启就好了
但生产环境出问题造成业务中断

(生产环境)误删 glibc +1
还不是删了那个 symlink，是把那个 so 文件删了

兼职遇到的垃圾公司

@RobertYang 你的意思是"Nginx 开机后不能自动由 systemd 启动，但可以手动执行 systemctl start nginx.service 来启动"是吗？

检查一下 /usr/lib/tmpfiles.d 目录，有无 nginx 相关的文件。
可能 nginx 要在一个 tmpfs 的挂载点的某个子目录下创建 lock 或 pidfile，而这个子目录重启后没被创建。
需要用 tmpfiles 解决。syntax 参考该目录下其他文件即可。

journalctl -xe -u nginx.service 的输出？

依赖硬盘的可靠性 ×
RAID5/RAID1+离线备份 √

@xudzhang
检索 openssl 和 error 7 得到一结果，或有帮助:
https://serverfault.com/questions/653144/openssl-verify-error-7-at-1-depth-lookupcertificate-signature-failure
从这篇问答来看似乎是用户证书签名问题。

使用`openssl x509 -in {path_to_client_cert} -noout -text`看一下客户端证书所用签名算法。
另外，用`openssl verify -CAfile {path_to_client_verify_ca} {path_to_client_cert}`测试下签发的证书有无问题。

@xudzhang 很抱歉，我恐怕很难透过这些信息提供帮助

我检索了 nginx+{错误信息中的数字*}(其余的信息似乎都是 x.509 证书的一些字段)，但无法找到任何有帮助的结果。
客户端有什么错误出现？
你可以尝试从客户端 /服务器抓一下包吗？

*:debug 6024|9450|error:7 等

用 OpenSSL 管理 CA，可参考 https://jamielinux.com/docs/openssl-certificate-authority/

ssl_client_certificate file;
ssl_verify_client on | off | optional | optional_no_ca;
ssl_verify_depth number;

你只需要关注以上三行
其中第三行的解释

(用于客户端验证的，下同)根 CA ------第 0 层
|
|_____中间 CA(a)-------第 1 层
| |
| |________用户 A 的证书----第 2 层
| |________用户 B 的证书----第 2 层
|_____用户 C 的证书----第 1 层

如果你把 depth 设为 1，只有 C 的证书会被信任；如果设成 2，所有三个用户的证书都被信任。
如果设成 0，则需要将根 CA 换成(唯一的)被信任的用户证书，且只有这个用户被信任。

一般地，如果证书的拓扑结构不是很复杂(压根没有中间 CA)，设为 1 即可。

用于 SSL 双向认证的 CA 证书不需要也不应该是一个商业 CA。