Hi I’m using the M1 for developing automation and tooling to get Discourse running. The discourse-setup script have an issue with recognizing ARM based CPUs and failing with the following error. This resulted in the container not starting. In my case I’m going with the web + data container approach so it’s the web_container that fails to start.
./discourse-setup: line 261: *0: syntax error: operand expected (error token is "*0")
./discourse-setup --two-container
The configuration file containers/web_only.yml already exists!
. . . reconfiguring . . .
Saving old file as web_only.yml.2022-06-12-062509.bak
Stopping existing container in 5 seconds or Control-C to cancel.
WARNING: Support for aarch64 is experimental at the moment. Please report any problems at https://meta.discourse.org/tag/arm
Press any key to continue
WARNING: We are about to start downloading the Discourse base image
This process may take anywhere between a few minutes to an hour, depending on your network speed
Please be patient
aarch64: Pulling from discourse/base
Digest: sha256:a2ce381fdc4fed59fe160fb01b79bce0d5266f59ad907a22f3399772c8711791
Status: Image is up to date for discourse/base:aarch64
docker.io/discourse/base:aarch64
WARNING: containers/web_only.yml file is world-readable. You can secure this file by running: chmod o-rwx containers/web_only.yml
web_only was not started !
./discourse-doctor may help diagnose the problem.
./discourse-setup: line 261: *0: syntax error: operand expected (error token is "*0")
Hostname for your Discourse? [discourse.example.com]:
Hi yes I am also running on Linux, not the MacOS. I am using a full RHEL9 image, not UBI, via UTM on the M1. So the issue is indeed related to Linux. I did stumple across a few threads about the dev team using M1 after I posted this PR and thread but without looking this further I suspect that is related to the dev team using another way to bootstrap?
I think there’s a mis-understanding here. I’m not trying to do development on Discourse itself. I’m also not trying to run Discourse in production on M1. What I’m trying to do are:
Write automation code to manage my infrastructure
This includes installation and periodic upgrade of Discourse.
The work will be done on my M1 laptop, using a RHEL9 image running via UTM.
This involves having the automation code to do the installation and bootstrap of Discourse within the RHEL9 VM.
Run Discourse on Intel based servers
The automation code will be deployed on a RHEL based server for UAT and production environments.
So unless I’m mistaken there are no additional changes aside required because I’m not trying to run in MacOS. If there are additional changes that are required beyond what’s in the PR then I guess I’ll move on to get a proper server to do this on but is that the case? On the other hand is there any issue with the PR submitted that can block it from being merged given it is already done?
Your original post is asking for Apple M1 support for the production install package. The problem is there’s no production hardware which uses the new Apple processors.
Hence my question: does it make sense to add this support, when no Production/M1 installation scenario is possible?
Wouldn’t it make more sense to develop this in an environment where your hardware is more representative of the final install scenario?
That must be a misunderstanding. I said “I’m using the M1 for developing automation and tooling to get Discourse running” on the original post. It’s for developing automation, not for running Discourse.
Yes it’d be nice to run it on representative hardware but this is for developing the tooling to get Discourse installed and started, and nothing more. Sometimes I’m on the road and I want to be able to do this with my M1 laptop only, un-tethered from the machines sitting in some DC requiring me to get a VPN connection going.
I understand what you’re trying to do, all I’m saying is that the production install doesn’t install on M1, because the M1 can’t be used in production.
This isn’t strictly true, the Raspberry Pi for example uses an ARM SoC, and discourse installs just fine, per:
Okay so I guess I was wrong in saying it’s ARM Based CPU as the issue is only with M1?
Anyway here is what I did …
Check out a new branch
discourse-setup runs fine with the change on the PR but then it kicks off launcher which would then check if I have the latest code on master. So I checked out a new branch and put the change on the new branch. I have also added an entry in /etc/hosts so when it checks if I’m running on the domain I said I’m running on, it pass the test.
Run discourse-setup again
This time it ran fine including the launcher to do the build and started a container.
Following is what I see towards the end of the output. I tried browsing to http://127.0.0.1 I see only a page with the default nginx. Probably it really doesn’t work afterall on the M1 due to some other issues. Will test out on a proper Intel based system. Although for the purpose of checking if the process works and we have something listening on port 80 / 443 it’s fine but would be nice to have the ability to actually service a page.
I, [2022-06-14T15:29:42.810750 #1] INFO -- : Replacing (?-mix:#?ACCOUNT_EMAIL=.+) with ACCOUNT_EMAIL=$$ENV_LETSENCRYPT_ACCOUNT_EMAIL
in /shared/letsencrypt/account.conf
I, [2022-06-14T15:29:42.811886 #1] INFO -- : Replacing (?-mix:ssl_certificate_key.+) with ssl_certificate_key /shared/ssl/$$ENV_DISCOURSE_HOSTNAME.key;
ssl_certificate_key /shared/ssl/$$ENV_DISCOURSE_HOSTNAME_ecc.key;
in /etc/nginx/conf.d/discourse.conf
I, [2022-06-14T15:29:42.812148 #1] INFO -- : Replacing (?-mix:add_header.+) with add_header Strict-Transport-Security 'max-age=63072000'; in /etc/nginx/conf.d/discourse.conf
I, [2022-06-14T15:29:42.812430 #1] INFO -- : Replacing location @discourse { with location @discourse {
add_header Strict-Transport-Security 'max-age=31536000'; # remember the certificate for a year and automatically connect to HTTPS for this domain in /etc/nginx/conf.d/discourse.conf
I, [2022-06-14T15:29:42.813521 #1] INFO -- : > echo "Beginning of custom commands"
I, [2022-06-14T15:29:42.814803 #1] INFO -- : Beginning of custom commands
I, [2022-06-14T15:29:42.814856 #1] INFO -- : > echo "End of custom commands"
I, [2022-06-14T15:29:42.816137 #1] INFO -- : End of custom commands
I, [2022-06-14T15:29:42.818177 #1] INFO -- : Terminating async processes
I, [2022-06-14T15:29:42.819361 #1] INFO -- : Sending INT to HOME=/var/lib/postgresql USER=postgres exec chpst -u postgres:postgres:ssl-cert -U postgres:postgres:ssl-cert /usr/lib/postgresql/13/bin/postmaster -D /etc/postgresql/13/main pid: 57
2022-06-14 15:29:42.819 UTC [57] LOG: received fast shutdown request
I, [2022-06-14T15:29:42.820068 #1] INFO -- : Sending TERM to exec chpst -u redis -U redis /usr/bin/redis-server /etc/redis/redis.conf pid: 118
118:signal-handler (1655220582) Received SIGTERM scheduling shutdown...
2022-06-14 15:29:42.829 UTC [57] LOG: aborting any active transactions
2022-06-14 15:29:42.832 UTC [57] LOG: background worker "logical replication launcher" (PID 66) exited with exit code 1
2022-06-14 15:29:42.835 UTC [61] LOG: shutting down
118:M 14 Jun 2022 15:29:42.866 # User requested shutdown...
118:M 14 Jun 2022 15:29:42.867 * Saving the final RDB snapshot before exiting.
118:M 14 Jun 2022 15:29:42.876 * DB saved on disk
118:M 14 Jun 2022 15:29:42.876 # Redis is now ready to exit, bye bye...
2022-06-14 15:29:42.958 UTC [57] LOG: database system is shut down
sha256:5f552461c03594fde4b917c0e995c5f63a777b44ee1638e0367c22a29fe1ec16
ef60feb320f8684423dcb5c3ca6062226d937cd72a642485052fa641f15cbc01
+ /usr/bin/docker run --shm-size=512m -d --restart=always -e LANG=en_US.UTF-8 -e RAILS_ENV=production -e UNICORN_WORKERS=4 -e UNICORN_SIDEKIQS=1 -e RUBY_GLOBAL_METHOD_CACHE_SIZE=131072 -e RUBY_GC_HEAP_GROWTH_MAX_SLOTS=40000 -e RUBY_GC_HEAP_INIT_SLOTS=400000 -e RUBY_GC_HEAP_OLDOBJECT_LIMIT_FACTOR=1.5 -e DISCOURSE_DB_SOCKET=/var/run/postgresql -e DISCOURSE_DB_HOST= -e DISCOURSE_DB_PORT= -e LETSENCRYPT_DIR=/shared/letsencrypt -e DISCOURSE_FORCE_HTTPS=true -e LC_ALL=en_US.UTF-8 -e LANGUAGE=en_US.UTF-8 -e EMBER_CLI_PROD_ASSETS=1 -e DISCOURSE_HOSTNAME=dev.bogus.com -e DISCOURSE_DEVELOPER_EMAILS=support@bogus.com -e DISCOURSE_SMTP_ADDRESS=smtp-relay.gmail.com -e DISCOURSE_SMTP_PORT=587 -e DISCOURSE_SMTP_USER_NAME=support@bogus.com -e DISCOURSE_SMTP_PASSWORD=stupidpassword -e DISCOURSE_SMTP_DOMAIN=dev.bogus.com -e DISCOURSE_NOTIFICATION_EMAIL=noreply@dev.bogus.com -e LETSENCRYPT_ACCOUNT_EMAIL=me@example.com -h bogusdev-app -e DOCKER_HOST_IP=172.17.0.1 --name app -t -p 80:80 -p 443:443 -v /var/discourse/shared/standalone:/shared -v /var/discourse/shared/standalone/log/var-log:/var/log --mac-address 02:f1:a1:42:8a:5f local_discourse/app /sbin/boot
0be6584a62912bae1d517882fde2a5bf61d1c39466448803be811fbd777c87a5
[root@bogusdev discourse]#
[root@bogusdev discourse]# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
0be6584a6291 local_discourse/app "/sbin/boot" 35 seconds ago Up 34 seconds 0.0.0.0:80->80/tcp, :::80->80/tcp, 0.0.0.0:443->443/tcp, :::443->443/tcp app
[root@bogusdev discourse]#
