@cnt2ex 我对你和 @Jirajine 的整个话题没有参与讨论的欲望，他说的因为 security critical 而一直升级的合理性我也不帮他辩护（事实上我也不同意）。

只是针对你说的“一个包 5.1.0 的版本存在严重安全漏洞，我只需要 5.1.1 的版本，或者是 5.2.x 的版本修复这个漏洞，不代表我就一定要更新到 6.8.1”这段。

你认为 5.1.0 有严重 security 漏洞，你升到 5.1.1 修复了，就不需要继续升级了。但如果上游的浏览器开发团队坚持 rolling 发布，过时的版本哪怕安全漏洞也不修，想要解决安全问题就要跟着它升到很信的版本呢？如果 5.1.0 里的某个严重安全漏洞过了很久才被人发现，这时上游发布的版本已经是 5.2.x 甚至 6.8.x 了，它只会在 6.8.x branch 里修这个漏洞，已经不管 5.2.x 了，你还想要一个 5.1.1 ，跟谁去要呢？浏览器团队已经不管这事了。那只能 distro 软对来做 backport……然后这么大一个软件，并不能指望 distro 团队的力量跟的上，即使能力有，也不能指望人家愿意往这上面投精力，毕竟这个“特定的”浏览器没有那么刚需，人家还有肯出 ESR 版的保底浏览器呢。

再重申一边，我不支持 @Jirajine 的观点。我同意你举的例子，很多服务器基础设施软件的安全更新行为足以证明“security critical 这一点，根本无法作为一个包"必须要一直升级的程序"的理由”。但是，回到某个“特定的”浏览器这事，人家上游怎么发版，是人家自己说了算的，人家就是要 rolling ，就是不管旧版本的 branch ，那么对这个“特定的”软件的“security critical”保障，那就只能靠追新来解决。说到底是 symver point release 的 distro 跟 rolling release 的应用程序之间维护方式的矛盾，只是个特例，咱们拿具体程序来讨论的时候就是说的这个特例。

@cnt2ex 他说的 backport 看来是作为一个通用词，不是说指 deb 系发行版里的`backports`这个 repo

不过“一个包 5.1.0 的版本存在严重安全漏洞，我只需要 5.1.1 的版本，或者是 5.2.x 的版本修复这个漏洞，不代表我就一定要更新到 6.8.1”这事不一定可行。虽然大部分基础设施类软件的上游一般都会在受支持的版本里仍然提供 critical fix ，但有一种情况，可能 distro 里打包的随着时间已经不受上游支持了，那就只能 distro 自己 backport 了；还有一种情况就是像 chromium 这样，上游一直在 rolling ，并不会维护特定的 LTS 版本，要安全补丁只能跟着更新，而且代码量又巨大，distro 做不来 backport 的。

上辈子加班狗猝死穿越过来的

Cannnical 历史上搞 upstart 搞 unity 最终都坚持不下去了……目测 snap 也火不起来。

比如赵公堤、花圃、乌龟潭之类，在杨公堤以西的一些地方。其实就连曲院风荷的西边都没那么多人。

即便是西湖景区，除了北山-湖滨-南山-苏堤一圈，刚好是西湖核心打卡区+密集商业区之外，稍微外围一点的景点也没有很多人。

要买股票开券商账户好了，费率汇率什么的比银行合算多了，然后 FPS 转账过去

另外 logrotate 基本上不用自己考虑用什么用户身份手工调用的问题，因为它是放在/etc/cron.xxxxly/ 下面的配置里自动定时调用的

@GoodRui 哦，我误解你的意思了，以为“量大的用户一天一个 error.log 就几个 G 了...”这句话是嫌按天切分单个文件太大，主贴和后面说“用第三方程序分割、归档、检索 nginx 日志”是想找更细粒度的切法

1. 找所在国当地的朋友帮忙
2. anytimemailbox

@gooddayup 我是手机开了八达通。B1 也支持支付宝、微信。车门口有两个机具，注意看清刷哪个。

@GoodRui logrotate 可以设置切分的周期，最小单位是每小时切一次。如果日志增长不均匀，怕每小时切一次在低增长时段切得太碎，还可以设置仅超过指定的大小才切分。

@care

有空可以看看两本老书：《 SQL 沉思录》、《 SQL 反模式》。

如果系统负载不是很高的话，还有一个办法，让 nginx 把日志写进 syslog ，在 rsyslog 的配置里去指定落盘位置和文件权限，甚至可以转发到中央日志服务器，本机就不管这些糟心事了。

@GoodRui 人肉测试了一下，删掉日志后 systemd 重新启动 nginx.service 新的日志文件是 root 的了……
不过 logrotate -f 手工强制卷了一下日志，归档完了后，新的日志文件就又是 www-data:adm 了。

`
root@asusz97a:/var/log/nginx# ls -al
总计 12
drwxr-xr-x 2 root adm 4096 4 月 29 日 20:23 .
drwxr-xr-x 25 root root 4096 4 月 28 日 00:00 ..
-rw-r--r-- 1 root root 162 4 月 29 日 20:26 access.log
-rw-r--r-- 1 root root 0 4 月 29 日 20:23 error.log
root@asusz97a:/var/log/nginx# cat access.log
::1 - - [29/Apr/2024:20:26:35 +0800] "GET / HTTP/1.1" 200 615 "-" "curl/8.7.1"
::1 - - [29/Apr/2024:20:26:38 +0800] "GET /1434 HTTP/1.1" 404 153 "-" "curl/8.7.1"
root@asusz97a:/var/log/nginx# logrotate -f /etc/logrotate.d/nginx
root@asusz97a:/var/log/nginx# ls -al
总计 12
drwxr-xr-x 2 root adm 4096 4 月 29 日 20:26 .
drwxr-xr-x 25 root root 4096 4 月 28 日 00:00 ..
-rw-r----- 1 www-data adm 0 4 月 29 日 20:26 access.log
-rw-r--r-- 1 root root 162 4 月 29 日 20:26 access.log.1
-rw-r--r-- 1 www-data root 0 4 月 29 日 20:23 error.log
`

但凡肯花几秒钟看一下 man su 就知道了。DESCRIPTION 小节的第三段文字：

For backward compatibility, su defaults to not change the current directory and to only set the environment variables HOME and SHELL (plus USER and LOGNAME if the target user is not root). It is recommended to always use the --login option (instead of its shortcut -) to avoid side effects caused by mixing environments.

我这里说的 www-data ，对应你的 nginx 用户

apt 安装的 nginx ，初始日志文件是安装完后的善后脚本（ /var/lib/dpkg/info/nginx-common.postinst ）里创建的，每天日志切分后的维护是在 /etc/logrotate.d/nginx 里配置的。这两个操作都把新的日志文件设置成 owner 为 www-data:adm ，设置 mode 为 0640

趁着你还是初学者，用 pg ，培养严谨的好习惯，养成技术品位。