服务器维护

更换源需注意处理器架构。

将网站迁移到华为云之后,便陆陆续续地遇到一些,其中有一个我最近才注意到。我把系统升级成 Ubuntu 20.04,软件源也换成了清华镜像,但在更新源时出现了如下错误:

E: Failed to fetch https://mirrors.tuna.tsinghua.edu.cn/ubuntu/dists/focal/main/binary-arm64/Packages  404  Not Found [IP: x.x.x.x 443]
E: Failed to fetch https://mirrors.tuna.tsinghua.edu.cn/ubuntu/dists/focal-updates/main/binary-arm64/Packages  404  Not Found [IP: x.x.x.x 443]
E: Failed to fetch https://mirrors.tuna.tsinghua.edu.cn/ubuntu/dists/focal-backports/universe/binary-arm64/Packages  404  Not Found [IP: x.x.x.x 443]
E: Failed to fetch https://mirrors.tuna.tsinghua.edu.cn/ubuntu/dists/focal-security/main/binary-arm64/Packages  404  Not Found [IP: x.x.x.x 443]
E: Some index files failed to download. They have been ignored, or old ones used instead.

重新访问镜像网站,发现了以下备注:

本镜像仅包含 32/64 位 x86 架构处理器的软件包,在 ARM(arm64, armhf)、PowerPC(ppc64el)、RISC-V(riscv64) 和 S390x 等架构的设备上(对应官方源为ports.ubuntu.com)请使用 ubuntu-ports 镜像。

错误提示说是无法读取 binary-arm64,那么云服务器应该是 arm64 架构,也就是要使用 ubuntu-ports 镜像才对。我将镜像链接中的 ubuntu 改成 ubuntu-ports 之后终于解决了问题。

限制日志文件大小

无奈旧坑才填,新坑又出。今天在升级软件时,显示空间不足。这就怪了,只运行了一个小网站的服务器怎么可能占用那么多空间呢?不懂就问,照例搜索一下,发现可能是日志文件太大了。日志一般存放在 /var/log/ 中:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
xxx@xxx:/# df -h
Filesystem      Size  Used Avail Use% Mounted on
udev            428M     0  428M   0% /dev
tmpfs            98M  1.4M   97M   2% /run
/dev/vda2        39G   37G     0 100% /
tmpfs           488M     0  488M   0% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           488M     0  488M   0% /sys/fs/cgroup
/dev/loop1       49M   49M     0 100% /snap/core18/1936
/dev/vda1       512M  3.5M  509M   1% /boot/efi
/dev/loop0       62M   62M     0 100% /snap/lxd/18328
/dev/loop3       62M   62M     0 100% /snap/lxd/18404
/dev/loop4       27M   27M     0 100% /snap/snapd/10243
/dev/loop5       27M   27M     0 100% /snap/snapd/10494
tmpfs            98M     0   98M   0% /run/user/0
xxx@xxx:/# cd /var/log/
xxx@xxx:/var/log# du -sh *
0       alternatives.log
44K     alternatives.log.1
376K    apache2
0       apport.log
8.0K    apport.log.1
4.0K    apport.log.2.gz
80K     apt
44K     auth.log
64K     auth.log.1
4.0K    auth.log.2.gz
4.0K    auth.log.3.gz
4.0K    auth.log.4.gz
0       bootstrap.log
68K     btmp
32K     btmp.1
4.0K    chrony
656K    cloud-init.log
28K     cloud-init-output.log
2.3M    dist-upgrade
92K     dmesg
92K     dmesg.0
20K     dmesg.1.gz
20K     dmesg.2.gz
20K     dmesg.3.gz
20K     dmesg.4.gz
24K     dpkg.log
56K     dpkg.log.1
4.0K    faillog
4.0K    fontconfig.log
8.0K    installer
3.9G    journal #这个
20G     kern.log #这个
0       kern.log.1
491M    kern.log.2.gz
4.0K    kern.log.3.gz
67M     kern.log.4.gz
4.0K    landscape
4.0K    lastlog
108K    letsencrypt
4.0K    multi-queue-hw.log
4.0K    private
2.1G    syslog #这个
5.6G    syslog.1 #这个
122M    syslog.2.gz
258M    syslog.3.gz
20M     syslog.4.gz
0       syslog.5.gz
33M     syslog.6.gz
17M     syslog.7.gz
4.0K    tallylog
0       ubuntu-advantage.log
8.0K    unattended-upgrades
8.0K    upgrade
4.0K    wtmp

果然揪出了几个吸血鬼。虽然这只是一些临时文件,但也不太敢随意删除,于是再搜索一下,找到了妥善的处理办法,即 > 文件名以及

1
2
find /var/log/ -type f \( -name "*.gz" -o -name "*.1" -o -name "*.old" \) -delete
find /var/log/ -type f -exec truncate -s 0 {} \;

而对于 journal,我参照 systemd/Journal 作了如下修改:

1
2
3
vim /etc/systemd/journald.conf #打开配置文件
#设置最大值 SystemMaxUse=50M
systemctl restart systemd-journald #重启服务

一番操作之后立马清爽了许多:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
xxx@xxx# du -sh *
0       alternatives.log
12K     apache2
0       apport.log
4.0K    apt
4.0K    auth.log
0       bootstrap.log
0       btmp
4.0K    chrony
0       cloud-init.log
0       cloud-init-output.log
8.0K    dist-upgrade
0       dmesg
0       dmesg.0
0       dpkg.log
0       faillog
0       fontconfig.log
8.0K    installer
417M    journal
141M    kern.log
4.0K    landscape
0       lastlog
4.0K    letsencrypt
0       multi-queue-hw.log
4.0K    private
141M    syslog
0       tallylog
0       ubuntu-advantage.log
4.0K    unattended-upgrades
4.0K    upgrade
0       wtmp

但这只是暂时的,日志文件会源源不断地生成,因此我根据这篇文章,使用 logrotate 来定期管理日志文件。

logrotate 程序是一个日志文件管理工具。用于分割日志文件,删除旧的日志文件,并创建新的日志文件,起到“转储”作用。可以节省磁盘空间。

以吸血最厉害的内核日志 kern.log 为例,它跟系统日志 rsyslog 有关。

vim /etc/logrotate.d/rsyslog

就可以看到包含 kern.log 在内的众多日志配置详情:

/var/log/syslog
{
        rotate 7
        daily
        missingok
        notifempty
        delaycompress
        compress
        postrotate
                /usr/lib/rsyslog/rsyslog-rotate
        endscript
}

/var/log/mail.info
/var/log/mail.warn
/var/log/mail.err
/var/log/mail.log
/var/log/daemon.log
/var/log/kern.log
/var/log/auth.log
/var/log/user.log
/var/log/lpr.log
/var/log/cron.log
/var/log/debug
/var/log/messages
{
        rotate 4
        weekly
        missingok
        notifempty
        compress
        delaycompress
        sharedscripts
        postrotate
                /usr/lib/rsyslog/rsyslog-rotate
        endscript
}

为了限制日志文件的大小,我在 {} 中添加 maxsize 200M。对于其他日志文件,可以在 /etc/logrotate.d/ 添加类似的配置。

至此,服务器与我皆一身轻松。