Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Engine not working correctly on M1 #103

Closed
YohannsMonnier opened this issue Jun 9, 2021 · 9 comments
Closed

Engine not working correctly on M1 #103

YohannsMonnier opened this issue Jun 9, 2021 · 9 comments

Comments

@YohannsMonnier
Copy link
Contributor

Q A
Bug report? yes
Feature request? no
BC Break report? no
RFC? no
Version 1.9.1
Environment Mac (M1)

Dear @Plopix ,

I have tested eZLaunchpad more this week, and in fact it is not working perfectly :

  1. RAM is not managed correctly : As the engine is not based on an Apple M1 architecture (arm64v8 ?), the RAM is not correctly set up and we have exhausted memory at 256Mo even if we assign 8Go of Ram to docker)

See this issue for examples that have same kind of issue because of not correct architecture : docker/for-mac#5204

  1. If I force to build a dedicated version for the Apple M1 architecture - all other library won't work, especially concerning PHP GD installation and configuration.

Available to let you test different option on my machine,

Yohann

@Plopix
Copy link
Collaborator

Plopix commented Jun 17, 2021

I was off for 3 weeks (👶 -> 🍼 )
I'll have a look next week.

The best way would still be for me to get an M1 ;-) (https://github.com/sponsors/Plopix)

@YohannsMonnier
Copy link
Contributor Author

dear @Plopix ,

still on M1, ~/ez command does not find system env variables anymore.

I don't know if this a problem on my computer or if this is a problem with the way env variables are set in the last version of ezlaunchpad.

I have tried to update ezlaunchpad and to init a new launchpad env to check before posting :

docker-compose -p yohanntestlaunchpad -f /Users/yohann/Projects/test_launchpad/provisioning/dev/docker-compose.yml -f /Users/yohann/Projects/test_launchpad/provisioning/dev/docker-compose-osx.yml exec --user www-data engine /var/www/html/project/composer_install.bash
WARN[0000] The PROJECTCOMPOSEPATH variable is not set. Defaulting to a blank string.
WARN[0000] The PROVISIONINGFOLDERNAME variable is not set. Defaulting to a blank string.
WARN[0000] The PROJECTCOMPOSEPATH variable is not set. Defaulting to a blank string.
WARN[0000] The PROJECTMAPPINGFOLDER variable is not set. Defaulting to a blank string.
WARN[0000] The HOST_COMPOSER_CACHE_DIR variable is not set. Defaulting to a blank string.
WARN[0000] The COMPOSER_CACHE_DIR variable is not set. Defaulting to a blank string.
WARN[0000] The PROJECTCOMPOSEPATH variable is not set. Defaulting to a blank string.
WARN[0000] The PROVISIONINGFOLDERNAME variable is not set. Defaulting to a blank string.
WARN[0000] The PROJECTPORTPREFIX variable is not set. Defaulting to a blank string.
services.engine.volumes array items[1,2] must be unique

Best regards,
Yohann

@Plopix
Copy link
Collaborator

Plopix commented Jul 19, 2021

Hello your docker-compose command cannot work like that. You need env vars. Run ez ps and at the top you will fine the full docker command.

You can also just do: ez ps c ;-)

@YohannsMonnier
Copy link
Contributor Author

Understood ! Thank You Sébastien !

In fact I got an error, but trying to type the docker compose command without env variables cause it to fail before

Yohann

@YohannsMonnier
Copy link
Contributor Author

Indeed, my command was faulty because it lacked the env variables.

My real error is :

ez enter -v
www-data@47846dc7cb6a:~/html$ read /dev/stderr: bad file descriptor

@sklimaszewski
Copy link

I can confirm that the above issue is related not only to M1 Macs. I'm having same issue on i7 MacBook after running ez enter:
www-data@d6921704a8e3:~/html$ read /dev/stderr: bad file descriptor

I think it may be related to the newest docker-compose update. Docker for Mac has updated my docker-compose:
Docker Compose version v2.0.0-beta.6

@YohannsMonnier
Copy link
Contributor Author

@sklimaszewski I confirm your assumption.

I have deactivated this experimental feature and I have no more bad file descriptor.

Yohann

@hubformation
Copy link

hubformation commented Aug 29, 2021

@sklimaszewski and @YohannsMonnier thank you for the tip. I deactivated the experimental feature and it fixed the problem. I too am on an i7 MacBook and had the "bad file descriptor" when doing ez enter. I also was not able to do ez init anymore...

@Plopix
Copy link
Collaborator

Plopix commented Dec 29, 2021

close in favor or #107

@Plopix Plopix closed this as completed Dec 29, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

4 participants