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

[Ubuntu WSL 1] rymfony server:start cannot unwrap unexisting fpm-conf.ini #12

Closed
kayneth opened this issue Aug 3, 2020 · 8 comments
Closed

Comments

@kayneth
Copy link
Contributor

kayneth commented Aug 3, 2020

Hello!

First, thank you for your work!
I wanted to try it out on a WSL 1 Ubuntu. Everything worked perfectly with new:symfony and php:list. Here is the result for a PHP installation done with ASDF-VM

 | Binary path                           |
├───────────────────────────────────────┤
 | /home/dballandras/.asdf/shims/php     |
 | /home/dballandras/.asdf/shims/php-fpm |

But for server:start, i've got an error. I cannot write to ~/.rymfony/fpm-conf.ini. Here is the backtrace:

INFO - Starting PHP...
INFO - Using php-fpm
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 2, kind: NotFound, message: "No such file or directory" }', src/php/server_fpm.rs:90:20
stack backtrace:
   0: backtrace::backtrace::libunwind::trace
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.46/src/backtrace/libunwind.rs:86
   1: backtrace::backtrace::trace_unsynchronized
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.46/src/backtrace/mod.rs:66
   2: std::sys_common::backtrace::_print_fmt
             at src/libstd/sys_common/backtrace.rs:78
   3: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
             at src/libstd/sys_common/backtrace.rs:59
   4: core::fmt::write
             at src/libcore/fmt/mod.rs:1076
   5: std::io::Write::write_fmt
             at src/libstd/io/mod.rs:1537
   6: std::sys_common::backtrace::_print
             at src/libstd/sys_common/backtrace.rs:62
   7: std::sys_common::backtrace::print
             at src/libstd/sys_common/backtrace.rs:49
   8: std::panicking::default_hook::{{closure}}
             at src/libstd/panicking.rs:198
   9: std::panicking::default_hook
             at src/libstd/panicking.rs:218
  10: std::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:486
  11: rust_begin_unwind
             at src/libstd/panicking.rs:388
  12: core::panicking::panic_fmt
             at src/libcore/panicking.rs:101
  13: core::option::expect_none_failed
             at src/libcore/option.rs:1272
  14: rymfony::php::server_fpm::start
  15: rymfony::php::php_server::start
  16: rymfony::commands::serve::serve
  17: rymfony::main
  18: std::rt::lang_start::{{closure}}
  19: std::rt::lang_start_internal::{{closure}}
             at src/libstd/rt.rs:52
  20: std::panicking::try::do_call
             at src/libstd/panicking.rs:297
  21: std::panicking::try
             at src/libstd/panicking.rs:274
  22: std::panic::catch_unwind
             at src/libstd/panic.rs:394
  23: std::rt::lang_start_internal
             at src/libstd/rt.rs:51
  24: main
  25: __libc_start_main
  26: _start
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

I even touch the file and restarted the command but it did the same.

I will try to rebuild manually the project and search for the issue and report the result here! 😄

@Pierstoval
Copy link
Member

Yup, thanks for reporting this issue!

It's coming from this line, the path should be replaced with the one in the HOME environment variable instead of using ~ 😄

@Pierstoval Pierstoval reopened this Aug 3, 2020
@Pierstoval
Copy link
Member

Sorry for closing/reopening, I've just published an attempt to fix the issue (couldn't really reproduce it).

If you could retry it by downloading it (or rebuilding it with cargo build after fetching all changes) it would be great!

@kayneth
Copy link
Contributor Author

kayneth commented Aug 3, 2020

Thank you!
I didn't build it at first on my own.
I installed the Rust binary under the WSL environment, rebuilt the project from master then it works!

I have other issues that I will try to work on (this is certainly due to my messy environment 😅):

-> ERROR: [/home/dballandras/.rymfony/fpm-conf.ini:12] unknown entry 'systemd_interval'
It seems to not be supported by WSL by searching through Github.

If I rebuild the project without this line I can run the server with the following error spammed in the console.

ERROR: failed to retrieve TCP_INFO for socket: Protocol not available (92)

But I should fix this on my own since it's an error due to my environment even if I simply try it on standalone php-fpm -F -y ~/.rymfony/fpm-conf.ini

Thank you for your time 💯

@Pierstoval
Copy link
Member

Thanks for the details about your issue with WSL1!

As I'm working on Windows too and I don't have WSL2, I'm going to look for a way to fix this. I also encountered the TCP_INFO error you mention, and I'm not yet sure to know where it comes from.

I'll look at this when I have more time, unless someone wants to check it out first, of course 😄

@kevinpapst
Copy link
Contributor

@kayneth I added a basic check to deactivate systemd support on MacOS. Due to a missing test env I am not able to verify a possible check for WSL (to deactivate it there as well).

But this crate or this code seems to do the trick. Maybe a WSL user could give it a try and adapt this check: https://github.com/Pierstoval/rymfony/pull/14/files#diff-95e26a75eee9a232f210ff2018e5d5c4R82-R83

@kayneth
Copy link
Contributor Author

kayneth commented Aug 28, 2020

Hi @kevinpapst!
Thank you for this.
I will try to work on this.
Locally, on this WLS1 environment, I've added the script to check for WSL and to rebuild the binary. This is working properly.

I need to replace the script by a proper crate requirement and I will add a contribution with it. 👍

One more thing:
I will not be able to keep this WSL 1 environment after next friday. I will only have my personal WSL 2 environment. Then I won't be able to try it anymore on both. Unless it's easy to switch between those two versions. 😄

@Pierstoval
Copy link
Member

@kayneth I'm waiting for your contribution, because I'm still using WSL1 😉

@Pierstoval
Copy link
Member

As of the record, I noted that the FPM server doesn't work on my WSL1 setup.

I think it is caused by microsoft/WSL#2090 / microsoft/WSL#1982 , and Microsoft announced that it will never be fixed, so for some people, Rymfony on WSL1 will be unusable 😞

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants