# Admin dashboard won’t load after upgrade to v2.2.0.beta3 +36
**URL:** https://meta.discourse.org/t/admin-dashboard-won-t-load-after-upgrade-to-v2-2-0-beta3-36/99669
**Category:** Support
**Created:** [10월 16, 2018, 7:10오후 UTC](https://meta.discourse.org/t/admin-dashboard-won-t-load-after-upgrade-to-v2-2-0-beta3-36/99669 "2018-10-16T19:10:56Z")
**Posts on this page:** 20
**Page:** 2
### Author:  [@jerdog](https://meta.discourse.org/u/jerdog)
#### Post date: [10월 25, 2018, 7:56오후 UTC](https://meta.discourse.org/t/admin-dashboard-won-t-load-after-upgrade-to-v2-2-0-beta3-36/99669/23 "2018-10-25T19:56:49Z")
Whenever I do an `/admin/upgrade` I see a lot of these throughout:
**When it starts:**
```plaintext
Waiting for Unicorn to reload
Waiting for Unicorn to reload
Waiting for Unicorn to reload
Waiting for Unicorn to reload
Waiting for Unicorn to reload
Waiting for Unicorn to reload
Waiting for Unicorn to reload
Waiting for Unicorn to reload
Waiting for Unicorn to reload
Waiting for Unicorn to reload
Waiting for Unicorn to reload
Waiting for Unicorn to reload
Waiting for Unicorn to reload
Waiting for Unicorn to reload
Waiting for Unicorn to reload
Waiting for Unicorn to reload
Waiting for Unicorn to reload
Waiting for Unicorn to reload
Stopping 3 Unicorn worker(s), to free up memory
```
**And then this towards the end:**
```plaintext
Waiting for Unicorn to reload
Waiting for Unicorn to reload
Waiting for Unicorn to reload
Waiting for Unicorn to reload
Waiting for Unicorn to reload
Waiting for Unicorn to reload
Waiting for Unicorn to reload
Waiting for Unicorn to reload
Waiting for Unicorn to reload
Waiting for Unicorn to reload
Waiting for Unicorn to reload
Waiting for Unicorn to reload
Waiting for Unicorn to reload
Waiting for Unicorn to reload
Waiting for Unicorn to reload
```
I know that it’s normal - but I seem to see more of them than I used to
---
### Author:  [@jomaxro](https://meta.discourse.org/u/jomaxro)
#### Post date: [10월 25, 2018, 8:14오후 UTC](https://meta.discourse.org/t/admin-dashboard-won-t-load-after-upgrade-to-v2-2-0-beta3-36/99669/24 "2018-10-25T20:14:09Z")
Completely unrelated. That has to do with some work @tgxworld did to make post deploy migrations safer.
---
### Author:  [@j.jaffeux](https://meta.discourse.org/u/j.jaffeux)
#### Post date: [10월 26, 2018, 9:08오전 UTC](https://meta.discourse.org/t/admin-dashboard-won-t-load-after-upgrade-to-v2-2-0-beta3-36/99669/25 "2018-10-26T09:08:17Z")
@gerhard and I have a plan to fix this, it’s not related to reports, but how we get backups size.
---
### Author:  [@jerdog](https://meta.discourse.org/u/jerdog)
#### Post date: [10월 26, 2018, 8:40오후 UTC](https://meta.discourse.org/t/admin-dashboard-won-t-load-after-upgrade-to-v2-2-0-beta3-36/99669/26 "2018-10-26T20:40:59Z")
Awesome - is there a way to remove the backups for now so that the Dashboard works again until this is fixed?
---
### Author:  [@dax](https://meta.discourse.org/u/dax)
#### Post date: [10월 26, 2018, 8:49오후 UTC](https://meta.discourse.org/t/admin-dashboard-won-t-load-after-upgrade-to-v2-2-0-beta3-36/99669/27 "2018-10-26T20:49:43Z")
If you have S3 backups enabled try you can try to run this from the rails console:
```plaintext
./launcher enter app
rails c
SiteSetting.backup_location = 'local'
```
refresh the site and see if you can access the dashboard
---
### Author:  [@jerdog](https://meta.discourse.org/u/jerdog)
#### Post date: [10월 26, 2018, 9:39오후 UTC](https://meta.discourse.org/t/admin-dashboard-won-t-load-after-upgrade-to-v2-2-0-beta3-36/99669/28 "2018-10-26T21:39:27Z")
Instead of doing that I just did it from the Settings and reloaded the page and Dashboard stats work again - but I can’t rely on that as I need S3 backups… BUT this is a good workaround so that we can check stats until the full fix is in.
---
### Author:  [@dax](https://meta.discourse.org/u/dax)
#### Post date: [10월 26, 2018, 9:42오후 UTC](https://meta.discourse.org/t/admin-dashboard-won-t-load-after-upgrade-to-v2-2-0-beta3-36/99669/29 "2018-10-26T21:42:47Z")
Ah sorry, I thought that you were unable to enter the dashboard at all. The result is the same.
Then you need to wait for the official fix before reactivate the setting
---
### Author:  [@fearlessfrog](https://meta.discourse.org/u/fearlessfrog)
#### Post date: [10월 26, 2018, 9:44오후 UTC](https://meta.discourse.org/t/admin-dashboard-won-t-load-after-upgrade-to-v2-2-0-beta3-36/99669/30 "2018-10-26T21:44:47Z")
> [@j.jaffeux](#):
>
> @gerhard and I have a plan to fix this, it’s not related to reports, but how we get backups size.
I can confirm that changing ‘Settings / Backup / Backup location’ to ‘local’ from ‘Amazon S3’ means the dashboard loads quickly again.
Thanks for looking at it, and we’ll await the official fix at the next update.
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [10월 26, 2018, 9:54오후 UTC](https://meta.discourse.org/t/admin-dashboard-won-t-load-after-upgrade-to-v2-2-0-beta3-36/99669/31 "2018-10-26T21:54:34Z")
Does that mean that the new [Backup location](https://meta.discourse.org/t/backup-location/100397) is broken? Or does it mean that if you did it the old way it’s broken because of the change?
---
### Author:  [@gerhard](https://meta.discourse.org/u/gerhard)
#### Post date: [10월 27, 2018, 12:11오전 UTC](https://meta.discourse.org/t/admin-dashboard-won-t-load-after-upgrade-to-v2-2-0-beta3-36/99669/32 "2018-10-27T00:11:28Z")
I’m not sure what’s actually causing the timeout…
How many objects are in your backup bucket? Does Admin → Backups load without problems when `backup_location` is set to S3?
---
### Author:  [@fearlessfrog](https://meta.discourse.org/u/fearlessfrog)
#### Post date: [10월 27, 2018, 12:37오전 UTC](https://meta.discourse.org/t/admin-dashboard-won-t-load-after-upgrade-to-v2-2-0-beta3-36/99669/33 "2018-10-27T00:37:46Z")
Our /admin/backups page (or rather then underlying request for .backups.json) takes about 50 seconds to come up each time, so it looks like the culprit of why the dashboard times out.
There are six entries in the ‘filename’ list for us, as we only keep that amount of backups rolling in S3 for 7 days.
At a guess, it looks like when calling S3 for a file list or file size then it’s taking about 10 seconds per entry. Perhaps something changed in the AWS S3 client library recently?
---
### Author:  [@fearlessfrog](https://meta.discourse.org/u/fearlessfrog)
#### Post date: [10월 27, 2018, 12:59오전 UTC](https://meta.discourse.org/t/admin-dashboard-won-t-load-after-upgrade-to-v2-2-0-beta3-36/99669/34 "2018-10-27T00:59:44Z")
The backups to S3 seem to be working ok, which is good, as I did a manual backup and it worked.
One ‘funny’ is that there is a new entry at the bottom of the list, perhaps showing some mismatch between what’s in the DB and what is actually in S3?
Note: the odd ‘3a97e..gz’ entry at the bottom.
Our AWS S3 store looks like this:
Hmm, I wonder if it’s because we store our backups and uploaded files/image in the same bucket? I can see S3 enumerating on the bucketlist and then taking a long time, due to all the root level keys.
Let me try giving it a separate clean bucket of it’s own and seeing if that works better.
---
### Author:  [@fearlessfrog](https://meta.discourse.org/u/fearlessfrog)
#### Post date: [10월 27, 2018, 1:07오전 UTC](https://meta.discourse.org/t/admin-dashboard-won-t-load-after-upgrade-to-v2-2-0-beta3-36/99669/35 "2018-10-27T01:07:55Z")
Yes, that was it - problem solved. I created a clean new S3 bucket for the backup location and now the backup/index works quickly.
Problem Summary: With the introduction of direct backups to S3 using the new [Backup Location](https://meta.discourse.org/t/backup-location/100397) feature, the listing of objects in S3 at the ‘S3 backup location’ setting can potentially take a long time, and cause a timeout over 30 seconds of the /admin and /admin/backup pages. This didn’t used to matter before, as the local file system was used as an interim storage location, but with a direct S3 backup the backup/index needed to list all the S3 objects it found.
Solution: Choose a S3 backup bucket with less existing objects in it, i.e. do not share your S3 Uploads location with your Backup Location S3 bucket.
Thanks for info all - all working great now.
---
### Author:  [@fearlessfrog](https://meta.discourse.org/u/fearlessfrog)
#### Post date: [10월 27, 2018, 1:26오전 UTC](https://meta.discourse.org/t/admin-dashboard-won-t-load-after-upgrade-to-v2-2-0-beta3-36/99669/36 "2018-10-27T01:26:13Z")
Not sure if helpful, but one potential tweak to this would be to put the S3 backups with a ‘discoursebackup/’ prefix and then you could pass that here to filter the object.list call to AWS - that way it would filter it and return quickly without an empty bucket expected:
`@s3_helper.list(S3BACKUP_PREFIX).each do |obj|`
>
---
### Author:  [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [10월 27, 2018, 1:32오전 UTC](https://meta.discourse.org/t/admin-dashboard-won-t-load-after-upgrade-to-v2-2-0-beta3-36/99669/37 "2018-10-27T01:32:41Z")
> [@fearlessfrog](#):
>
> Problem Summary: With the introduction of direct backups to S3 using the new [Backup Location](https://meta.discourse.org/t/backup-location/100397) feature, the listing of objects in S3 at the ‘S3 backup location’ setting can potentially take a long time, and cause a timeout over 30 seconds of the /admin and /admin/backup pages. This didn’t used to matter before, as the local file system was used as an interim storage location, but with a direct S3 backup the backup/index needed to list all the S3 objects it found.
Hmm maybe @gerhard can chime in on that observation.
---
### Author:  [@fearlessfrog](https://meta.discourse.org/u/fearlessfrog)
#### Post date: [10월 27, 2018, 2:19오전 UTC](https://meta.discourse.org/t/admin-dashboard-won-t-load-after-upgrade-to-v2-2-0-beta3-36/99669/38 "2018-10-27T02:19:59Z")
I think it’s just an unlucky edge-case Jeff, in that:
- The S3 backups go in the root of the bucket chosen for backups, while ideally a location could be chosen within the bucket (a prefix for the S3 object keys).
- Some Discourse stand-alone installs will have the same bucket specified as their S3 upload as well, and due to the nature of that Uploads storage hierarchy means, that there are 230+ existing root objects in it (the hashing of upload locations uses many root prefixes or ‘directories’ in filesystem speak).
- S3 AWS .listObjects is notoriously slow without some sort of prefix filter.
- The new Backup Location gets its info direct from S3 now, which is why it became an issue and not before.
I doubt there are many like us that kept both the backups and uploads in the same bucket, and it was super easy to just create a new S3 backup bucket anyway (which can then have it’s own version lifecycle, Glacier etc) which is probably the most sensible deployment.
---
### Author:  [@gerhard](https://meta.discourse.org/u/gerhard)
#### Post date: [10월 27, 2018, 1:08오후 UTC](https://meta.discourse.org/t/admin-dashboard-won-t-load-after-upgrade-to-v2-2-0-beta3-36/99669/39 "2018-10-27T13:08:15Z")
> [@fearlessfrog](#):
>
> The S3 backups go in the root of the bucket chosen for backups, while ideally a location could be chosen within the bucket (a prefix for the S3 object keys).
`s3_upload_bucket` and `s3_backup_bucket` support prefixes. You can use `my-bucket-for-discourse-stuff/backups` without problems.
As you have experienced yourself, putting everything into the same bucket without using a prefix is a really bad idea. The solution is to either use the bucket exclusively for backups or to use a prefix for backups.
---
### Author:  [@Stephen](https://meta.discourse.org/u/Stephen)
#### Post date: [10월 27, 2018, 1:24오후 UTC](https://meta.discourse.org/t/admin-dashboard-won-t-load-after-upgrade-to-v2-2-0-beta3-36/99669/40 "2018-10-27T13:24:34Z")
> [@gerhard](#):
>
> putting everything into the same bucket without using a prefix is a really bad idea
Aside from this issue, you’re effectively combining data you’re publishing to the web with backups of everything including personally identifying user data.
With all the work done to secure the download of backups, I would be quite open to the idea of Discourse explicitly blocking the same bucket from being used in both cases.
---
### Author:  [@fearlessfrog](https://meta.discourse.org/u/fearlessfrog)
#### Post date: [10월 27, 2018, 6:23오후 UTC](https://meta.discourse.org/t/admin-dashboard-won-t-load-after-upgrade-to-v2-2-0-beta3-36/99669/41 "2018-10-27T18:23:14Z")
> [@gerhard](#):
>
> `s3_upload_bucket` and `s3_backup_bucket` support prefixes. You can use `my-bucket-for-discourse-stuff/backups` without problems.
You should put that in the help text for the setting? At the moment it just says the bucket name, implying the opposite. “_The Amazon S3 bucket name that files will be uploaded into. WARNING: must be lowercase, no periods, no underscores._”
I’m glad I figured out why ours (and others) Discourse dashboard’s were broken for so long.
Let me know when the fix is in that the listing of the backups doesn’t break the dashboard viewing.
---
### Author:  [@fearlessfrog](https://meta.discourse.org/u/fearlessfrog)
#### Post date: [10월 27, 2018, 6:26오후 UTC](https://meta.discourse.org/t/admin-dashboard-won-t-load-after-upgrade-to-v2-2-0-beta3-36/99669/42 "2018-10-27T18:26:47Z")
AWS S3 bucket boundaries are no more or less secure than S3 object ACLs. If the backup files are not marked for public then there is not more or less security risk than using a different bucket with different ACLs.
[Previous page](https://meta.discourse.org/t/admin-dashboard-won-t-load-after-upgrade-to-v2-2-0-beta3-36/99669.md?page=1)
[Next page](https://meta.discourse.org/t/admin-dashboard-won-t-load-after-upgrade-to-v2-2-0-beta3-36/99669.md?page=3)