debugging
This commit is contained in:
parent
b87c68c120
commit
e0fd1ad709
|
@ -15,6 +15,14 @@ Specific details of server-side errors are _never_ displayed to the public, as t
|
|||
|
||||
Each response from Mastodon’s web server carries a header with a unique request ID, which is also reflected in the logs. By inspecting the headers of the error page, you can easily find the corresponding stack trace in the log.
|
||||
|
||||
## **I'm not seeing much in my logs. How do I enable additional logging/debugging information?**
|
||||
|
||||
By default your logs will show `info` level logging. To see all debugging messages, modify the setting `RAILS_LOG_LEVEL` in your your `.env.production` file and set the logging level to `debug` and then restart the service that you're attempting to troubleshoot.
|
||||
|
||||
More information on other logging levels for this option can be found on the [Configuring your environment](https://docs.joinmastodon.org/admin/config/#rails_log_level) page.
|
||||
|
||||
The `debug` level can be very verbose and you should take care to change the log level back to a lower level once you have completed your troubleshooting.
|
||||
|
||||
## **After an upgrade to a newer version, some pages look weird, like they have unstyled elements. Why?**
|
||||
|
||||
Check that you have run `RAILS_ENV=production bin/rails assets:precompile` after the upgrade, and restarted Mastodon’s web process, because it looks like it’s serving outdated stylesheets and scripts. It’s also possible that the precompilation fails due to a lack of RAM, as webpack is unfortunately extremely memory-hungry. If that is the case, make sure you have some swap space assigned. Alternatively, it’s possible to precompile the assets on a different machine, then copy over the `public/packs` directory.
|
||||
|
|
Loading…
Reference in New Issue