There’s nothing wrong with the script, it was tested by another user just two days prior.
94: read -p "Enter the name of your domain [ex: www.webeindustry.com] " domain;
95: sed -i "s/"www.example.com"/$domain/g" discourse.conf;
It seems you’ve skipped this part.
I really had the wrong domain set up but I changed it the
/var/www/discourse/config/discourse.conf rebooted but still get the same error.
Crazy thought: can you please paste the output from
sudo dumpe2fs /dev/ploop10158p1
About the only idea I have left is that for some reason the block size of your filesystem is abnormally large. That would cause everything to appear to take up much more space…
Can’t use dumpe2fs:
dumpe2fs 1.42.12 (29-Aug-2014)
dumpe2fs: Operation not permitted while trying to open /dev/ploop41512p1
Couldn't find valid filesystem superblock.
OK, rather than trying to guess what the actual filesystem type is, can you please paste the contents of your
proc /proc proc defaults 0 0 none /dev/pts devpts rw 0 0 none /dev/shm tmpfs rw 0 0 cgroup /cgroups/blkio cgroup blkio 0 0 cgroup /cgroups/memory cgroup memory 0 0 cgroup /cgroups/devices cgroup freezer,devices 0 0 cgroup /cgroups/cpuset cgroup cpuacct,cpu,cpuset 0 0
Hm. OK. Apparently OpenVZ makes this sort of thing more opaque than we might like, since that tells me nothing about
My Discourse instance has run out of 25GB of space (Linode 1024 VPS). The only
files over 100MB were 7 backups, 225MB each, and one 700MB nginx log file. Hardly adding up to 2.5GB.
When I ran
./launcher cleanup, more than 10GB were freed up.
Clearly there’s a leak somewhere. I’d be curious how much disk space Docker takes up on other folks’ similar configurations. Right now, I have
root@localhost:~# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/root 24G 7.4G 16G 33% /
devtmpfs 494M 4.0K 494M 1% /dev
none 4.0K 0 4.0K 0% /sys/fs/cgroup
none 100M 340K 99M 1% /run
none 5.0M 0 5.0M 0% /run/lock
none 496M 0 496M 0% /run/shm
none 100M 0 100M 0% /run/user
/dev/mapper/docker-8:0-41527-352bef0[...] 9.8G 1.5G 7.8G 17% /var/lib/docker/devicemapper/mnt/352bef0[...]
If you are using device mapper, you are in a world of pain and suffering. Strongly not recommended. We block install on device mapper for a reason.
Well, I never did anything intentional or specific to end up with devicemapper. Never saw a warning, let alone been blocked from installing.
I installed Discourse around June 2015 (I think - is there a way to tell specifically?), so maybe devicemapper was the default back then for Docker on Linode kernels, after
Docker dropped the aufs requirement? I’m running Ubuntu 14.04.3 LTS (GNU/Linux 4.4.0-x86_64-linode63 x86_64) and have upgraded the Linode to KVM from Xen.
What exactly does this “world of pain” entail? Is it worth restoring a Discourse backup to an instance running on aufs?
Should there be some guidance in the
30-minute installation guide about aufs? Right now it assumes DigitalOcean, but folks may want to install on other hosts, for whatever reason.
The short version: It will work fine until it suddenly corrupts the file system; and then demons fly out of your nose, circle back behind you and strangulate you. Only one of these is an overstatement
Here are a few memorable quotes from the world of pain:
I am pretty sure launcher warns about non aufs these days.
Not a peep actually. I’ve just installed on a Ubuntu 14.04 LTS Linode. Here’s the full log.
docker info returning?
root@localhost:~# docker info
Server Version: 1.10.1
Storage Driver: devicemapper
Pool Name: docker-8:0-98371-pool
Pool Blocksize: 65.54 kB
Base Device Size: 10.74 GB
Backing Filesystem: ext4
Data file: /dev/loop0
Metadata file: /dev/loop1
Data Space Used: 2.075 GB
Data Space Total: 107.4 GB
Data Space Available: 19.82 GB
Metadata Space Used: 1.974 MB
Metadata Space Total: 2.147 GB
Metadata Space Available: 2.146 GB
Udev Sync Supported: true
Deferred Removal Enabled: false
Deferred Deletion Enabled: false
Deferred Deleted Device Count: 0
Data loop file: /var/lib/docker/devicemapper/devicemapper/data
WARNING: Usage of loopback devices is strongly discouraged for production use. Either use `--storage-opt dm.thinpooldev` or use `--storage-opt dm.no_warn_on_loop_devices=true` to suppress this warning.
Metadata loop file: /var/lib/docker/devicemapper/devicemapper/metadata
Library Version: 1.02.77 (2012-10-15)
Execution Driver: native-0.2
Logging Driver: json-file
Network: bridge null host
Kernel Version: 4.4.0-x86_64-linode63
Operating System: Ubuntu 14.04.1 LTS
Total Memory: 991.7 MiB
WARNING: No swap limit support
So odd … any idea why that test
Can't install Discourse with only 10 GB disk, run out of space is not running, try putting some
echo commands in launcher to see if its even hitting it?
@hedgehog, did you solve your original issue? I have the exact same problem on OVH VPS SSD 1 (10 GB SSD, 1 GB RAM).
Here is what seems to happen when installing Discourse on an
OVH VPS SSD 1 (10 GB SSD, 1 GB RAM) at $3.49/month:
After updating the system and installing git and docker, 6.5GB of drive space remain.
discourse-setup will start by creating a 2GB swap, so then 4.5GB of drive space remain.
discourse-setup will complain that it needs at least 5GB and it will stop.
Here is a workaround:
discourse-setup normally and enter the requested data
When asked to confirm the data (“Does it look good?”) open another SSH terminal and reduce the swap size to 1GB (see
here about how to proceed) Continue
discourse-setup until the end
Increase the swap size back to 2GB, just like you did it to reduce it
The resulting Discourse instance seems to work for now.