引导失败

安装
1

此机器是测试机。我之前在此机器上运行过 Discourse，但安装出错，未能更新到最新版本，我认为这是我的错误。删除整个 Discourse 目录并清理 Docker 后，我尝试进行全新安装，然后再导入实时数据库的备份。

奇怪的是，我仍然遇到相同的问题，并且无法解决。

这是失败的输出。我已经尝试过 discourse-doctor，但没有发现任何有用的信息。

...
I, [2022-06-04T18:42:29.087446 #1]  INFO -- : Terminating async processes
I, [2022-06-04T18:42:29.087672 #1]  INFO -- : Sending INT to HOME=/var/lib/postgresql USER=postgres exec chpst -u postgres:postgres:ssl-cert -U postgres:postgres:ssl-cert /usr/lib/postgresql/13/bin/postmaster -D /etc/postgresql/13/main pid: 42
I, [2022-06-04T18:42:29.087881 #1]  INFO -- : Sending TERM to exec chpst -u redis -U redis /usr/bin/redis-server /etc/redis/redis.conf pid: 103
2022-06-04 18:42:29.088 UTC [42] LOG:  received fast shutdown request
103:signal-handler (1654368149) Received SIGTERM scheduling shutdown...
2022-06-04 18:42:29.118 UTC [42] LOG:  aborting any active transactions
2022-06-04 18:42:29.123 UTC [42] LOG:  background worker \"logical replication launcher\" (PID 51) exited with exit code 1
2022-06-04 18:42:29.123 UTC [46] LOG:  shutting down
103:M 04 Jun 2022 18:42:29.154 # User requested shutdown...
103:M 04 Jun 2022 18:42:29.154 * Saving the final RDB snapshot before exiting.
103:M 04 Jun 2022 18:42:29.159 * DB saved on disk
103:M 04 Jun 2022 18:42:29.159 # Redis is now ready to exit, bye bye...
2022-06-04 18:42:29.201 UTC [42] LOG:  database system is shut down


FAILED
--------------------
Pups::ExecError: cd /var/www/discourse && su discourse -c 'bundle exec rake db:migrate' failed with return #<Process::Status: pid 1102 exit 1>
Location of failure: /usr/local/lib/ruby/gems/2.7.0/gems/pups-1.1.1/lib/pups/exec_command.rb:117:in `spawn'
exec failed with the params {"cd"=>"$home", "hook"=>"db_migrate", "cmd"=>["su discourse -c 'bundle exec rake db:migrate'"]}
bootstrap failed with exit code 1
** FAILED TO BOOTSTRAP ** please scroll up and look for earlier error messages, there may be more than one.
./discourse-doctor may help diagnose the problem.
69cb25658efb6f16e4479bb98a2d0278d72e56028865730841ac1efacc5b8d9d
==================== END REBUILD LOG ====================

服务器本身应该没问题——磁盘空间充足，其他资源也足够。有什么想法吗？

2

我需要看到更多日志，我认为，特别是要看看那个 rake 命令发生了什么。

请提供以下命令的输出：

free
df

如果您的日志中包含以下内容，也可能相关：
WARNING overcommit_memory is set to 0!

1 个赞
3

确实有：

103:M 04 Jun 2022 18:40:07.369 # WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.

这是您要求的其余部分：

root@testserver-2021:/var/discourse# free
              total        used        free      shared  buff/cache   available
Mem:       16005396      353200    13366988        1100     2285208    15316292
Swap:             0           0           0
root@testserver-2021:/var/discourse# free -h
              total        used        free      shared  buff/cache   available
Mem:           15Gi       343Mi        12Gi       1.0Mi       2.2Gi        14Gi
Swap:            0B          0B          0B
root@testserver-2021:/var/discourse# df -h
Filesystem      Size  Used Avail Use% Mounted on
udev            7.7G     0  7.7G   0% /dev
tmpfs           1.6G  1.1M  1.6G   1% /run
/dev/sda1       226G   44G  173G  21% /
tmpfs           7.7G     0  7.7G   0% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           7.7G     0  7.7G   0% /sys/fs/cgroup
/dev/sda15       61M  5.2M   55M   9% /boot/efi
overlay         226G   44G  173G  21% /var/lib/docker/overlay2/c9457cf1821fb558a92c79e55bd6a70153b8ae0388732aa5eef17237b6924c25/merged
overlay         226G   44G  173G  21% /var/lib/docker/overlay2/6d350b54871378d4b0e7ac5d30e236df3bdd1c45cd3b5fb2e9ab67ffe7a1bba1/merged
tmpfs           1.6G     0  1.6G   0% /run/user/0
overlay         226G   44G  173G  21% /var/lib/docker/overlay2/104be98cc5c33e73e4119d2186b6d9d08123ffc79df872f48425e94a66ca6749/merged

我猜 overcommit 消息是由于 swap 为 0 导致的？奇怪的是，自从这个服务器存在以来，它从未改变过……

4

嗯……16G的内存相当大了，所以你可能觉得不需要交换空间。但我认为添加一些可能也没有坏处。如果看不到你的日志，我无法确定问题是内存不足。但如果是的话，设置过度提交模式可能会有帮助，无论你是否有交换空间。

6

您也可以尝试
dmesg | egrep -i "oom|memory"
来查看是否有进程因内存不足而被终止。

但同样，看到更多日志可能会有帮助。

编辑：哎呀，添加了 -i

1 个赞
7

我创建了一个交换区，并且设置了超额提交模式。但不幸的是，没有任何改变。

这是构建应用程序的完整日志 https://pastebin.com/raw/R2B8Wneu

我看到一些 Redis 失败，提示端口已被使用，但我不知道这是从哪里来的。

root@testserver-2021:~# sudo lsof -i -P -n | grep LISTEN
systemd       1            root   89u  IPv6  15961      0t0  TCP *:9090 (LISTEN)
systemd-r   573 systemd-resolve   13u  IPv4  10890      0t0  TCP 127.0.0.53:53 (LISTEN)
sshd        676            root    3u  IPv4  20387      0t0  TCP *:22 (LISTEN)
sshd        676            root    4u  IPv6  20389      0t0  TCP *:22 (LISTEN)
docker-pr   913            root    4u  IPv4  23665      0t0  TCP *:9100 (LISTEN)
docker-pr   921            root    4u  IPv6  21827      0t0  TCP *:9100 (LISTEN)
docker-pr   981            root    4u  IPv4  24732      0t0  TCP *:3003 (LISTEN)
docker-pr   989            root    4u  IPv6  22636      0t0  TCP *:3003 (LISTEN)
monitorix  1284       monitorix    3u  IPv4  27978      0t0  TCP *:8080 (LISTEN)
8

感谢您提供的日志 - 看起来像是 S3 设置问题（这方面我无法提供帮助，但我相信有人可以）。

I, [2022-06-05T09:06:10.144445 #1] INFO – : > cd /var/www/discourse & su discourse -c ‘bundle exec rake db:migrate’
rake aborted!
Discourse::SiteSettingMissing: s3_upload_bucket
/var/www/discourse/lib/file_store/s3_store.rb:267:in `s3_bucket’

9

干得好，Ed。谢谢。看起来 s3_bucket 在某个时候变成了 s3_upload_bucket，并且我在 containers/app.yml 中有这些配置，这似乎是导致问题的原因。至少在我将那里的 DISCOURSE_S3_BUCKET 更改为 DISCOURSE_S3_UPLOAD_BUCKET 后，现在构建顺利完成了。

我希望这类更改也能在构建过程中引入一个检查，以避免遇到这个问题——而且我们很幸运，我们总是在测试机上测试我们的更新。

1 个赞
10

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.