Hey All
I’ve run through the installation process multiple times now. Unfortunately, each time the entire process comes to a complete halt at
cd /var/www/discourse && chown -R discourse /var/www/discourse
I’ve tried to create the folder myself, since it didn’t even exist, but it doesn’t seem to have any impact. I’ve rebooted multiple times as well. I’m at a loss here.
What installation instructions are you following? It doesn’t look like https://github.com/discourse/discourse/blob/master/docs/INSTALL-cloud.md. Are you installing a development environment?
That’s exactly the guide that I’ve been following. I practically copy and paste all the commands into my terminal. It’s when I get the ./discourse-setup running… I get past putting all the information in… and then it goes through all the lines of configuring and installing everything.
Unfortunately, it installs some bundler-1.16.0, after doing a bunch of nginx stuff, and then gets stuck at the cd /var/www/discourse && chown -R discourse /var/www/discourse
I was wondering why it got stuck… so I went to look for the folder myself to see if I could manually grant it the proper ownership/permissions… but the folder doesn’t even exist.
Everything is being run as sudo. I’m on Ubuntu 17.1.
Oh dear!
I am such a sillyhead. Apparently, on my machine at least, it takes over 10 minutes to get past that step. It seems to be flowing right through the rest of the setup now!
So sorry, and thank you!
Yup, it cam take up to 30min for a fresh install and 20min for a rebuild. You probably should scale up to a high cpu vm for the install then scale back down afterwards.
A chown run is going to be disk-bound, not CPU-bound. I’m wondering what sort of archaic storage system you’ve got that it takes 10 minutes to chown the app tree.
Probably 
I had been running the server off an SSD until recently. That ended up completely dying on me (it was a fairly old SSD, so I was kind of expecting it to happen eventually). The server’s currently running on some old laptop HDD that I had laying around.
Thanks for the reply! Glad to know that the process will speed up once I can get my hands on another SSD for the server!
I realize that chown doesn’t always run slow. It is only when there has been a previous, unsuccessful attempt at rebuild.
If it is a fresh rebuild, then chown seems to complete very quickly. If there has been a previous failed rebuild (e.g. a typo in app.yml), then it takes forever to chown. Perhaps the old files are still there?
Maybe you can time it, and test this hypothesis and get us some data?
Well, I have done it several times since then. All clean ./launcher rebuild app without prior failures.
Run on multiple VM’s with the same sizes, RAM and CPU’s.
Sometimes the chown complete within seconds. Sometimes the chown takes forever. And the larger installations may be the fast ones.
I’ll experiment some more…
BTW… it may have something to do with running ./launcher cleanup prior. It seems that chown runs very fast after a cleanup, but need more evidences.
EDIT: My VM’s all have 2 CPU’s, 3GB RAM and HDD (not SSD). So this may magnify the impacts of chown a bit.
Well, cleanup isn’t it. Cleaned up and chown still took 7 minutes. Back to the drawing board.
Hi, bit of a bump, but I have had the same problem since I first tried Discourse.
From my understanding, chown will set the ownership of all files, irregardless of the current owner. Of course after the first setup the files should already be owned by the discourse user, so there is no need to change them all, just the new ones.
On my install I’ve changed the web.template.yml to use find to change only files that aren’t already owned by discourse. That part of a rebuild used to take 8+ minutes (VM on ZFS with no SSD) and now its almost instant.
There are a couple of instances of chown in the template, but I think the “main” one is this one:
https://github.com/discourse/discourse_docker/blob/master/templates/web.template.yml#L165
Which I’ve replaced with:
find $home ! -user discourse -exec chown discourse {} \+
Which finds all files not owned by discourse and executes chown on them.
Maybe could this be put into the native application template?
I haven’t rebuilt the app on disk for a while now, since the upgrade via web admin console works like a charm. Upgrading in the docker container works different to the shell rebuild as far as I would guess for now.
git pulled plenty of changes.
1392 files changed, 63951 insertions(+), 41658 deletions(-)
I don’t have exact times, but I’d say 10 minutes at least where the Docker container was just idle with chown (did a docker exec to inspect what it was doing). System here is running with limited IOPs on a hosting platform.
One could also install parallel or alter the way find executes chown in multiple processes, e.g. per directory. Would such make sense for a PR?
If you’re IOPS bound, trying to run multiple IOPS-heavy instances of an operation in parallel is unlikely to provide any benefit.
True that, didn’t think of that. Thanks 
I don’t know whether the partial chown brings some general performance improvements, I’ll need to test that.