30 lines
2.4 KiB
Markdown
30 lines
2.4 KiB
Markdown
---
|
||
title: 故障分析
|
||
menu:
|
||
docs:
|
||
weight: 120
|
||
parent: admin
|
||
---
|
||
|
||
## **我看到一个故障页说一些东西出错了。我怎么找出哪里出错了？**
|
||
|
||
所有带堆栈追踪（stack traces）的错误信息都将会被写入系统日志。当使用systemd时，可使用 `journalctl -u mastodon-web`（替换以相应的服务名） 来浏览每个服务的日志。当使用Docker时，与之类似：`docker logs mastodon_web_1`（替换以相应的容器名）。
|
||
|
||
服务端详细错误信息将*永不会*公开显示，因为它们可能会暴露你的内部设置，并为攻击者提供线索，让他们了解如何更好的入侵或如何更高效的滥用。
|
||
|
||
来自Mastodon web服务器的每一个响应都带有独一无二的请求ID（request ID），该ID也将反映在日志中。通过检查错误页的请求头，你可以在日志中轻松找到与之对应的堆栈追踪（stack traces）。
|
||
|
||
## **升级新版本后，有些页面看起来很奇怪，就像它们含有未设置样式的元素一样。为什么？**
|
||
|
||
检查升级后，你是否运行 `RAILS_ENV=production bin/rails assets:precompile` 并重启Mastodon web 进程。因为这看起来像提供了过期的样式与脚本。这也有可能由于内存缺乏导致预编译失败，很不幸webpack会占用大量内存。如果是这个原因，请确保你已经分配了swap空间。另外，也可以在另一台机器上预编译静态文件，然后把它们复制至 `public/packs` 目录。
|
||
|
||
## **升级新版本后，一些请求失败了，日志中的错误信息是 missing columns or tables。为什么？**
|
||
|
||
检查升级后，你是否运行 `RAILS_ENV=production bin/rails db:migrate`。因为这看起来Mastodon代码访问了一个更新或更旧的数据库schema。如果你使用PgBouncer，请确保此命令直接连接PostgreSQL，因为PgBouncer不支持迁移过程中的锁表操作。
|
||
|
||
## **我试图运行 `tootctl` 或 `rake`/`rails` 命令，但我得到 uninitialized constants 错误信息。哪里出错了？**
|
||
|
||
检查你是否在命令前使用 `RAILS_ENV=production` 指定正确的环境。默认情况下，假定使用开发环境，因此代码尝试加载开发相关gem。然而，在生产环境中，我们避免安装这些gem。这就是错误的来源。
|
||
|
||
{{< translation-status-zh-cn raw_title="Troubleshooting errors" raw_link="/admin/troubleshooting/" last_tranlation_time="2020-05-08" raw_commit="ad1ef20f171c9f61439f32168987b0b4f9abd74b">}}
|