I start the jekyll server inside bash. It serves up pages until the first time it detects the content has changed and it will do the rebuild. After that, replies on localhost:4000 stop. This happens if I start jekyll as bundle exec jekyll serve or just jekyll serve. It also happens if I start either of these commands in the background.
When I try to stop jekyll with ^C, I never get the prompt back. If I started the process in the background, kill -9 <pid> doesn’t work either. The server still shows up with ps -ef. Even more maddening, if I quit WSL, the process still lives in Windows space. I can see it in the Task Manager as bash.exe. I can’t kill it from Task Manager, either, the process is grayed out. The only thing that will stop the process for me is a reboot.
I have a workaround where I rsyncs3cmd sync the _site folder to an S3 bucket that I have set up as a staging site, but that’s a pain to do for hours on end.
I’ve used jekyll serve successfully in the past on a Mac and Linux without any problems. I’m assuming this is some oddity of using WSL, but I haven’t had this type of issue before. Ideas?
Unrelated, when you get this working I would recommend livereload if you don’t use it already. It will refresh your browser tab, in addition to the Jekyll rebuild. And trace flag gives error details which the usual error is too vague
You have to use a Ruby+Devkit version of the RubyInstaller and install the MSYS2 build tools to successfully install the wdm gem.
When I ran jekyll new in 2018, my Gemfile ended with
# Windows does not include zoneinfo files, so bundle the tzinfo-data gem
gem "tzinfo-data", platforms: [:mingw, :mswin, :x64_mingw, :jruby]
# Performance-booster for watching directories on Windows
gem "wdm", "~> 0.1.0" if Gem.win_platform?
The --force-polling option seems to have done the trick. I already had the tzinfo and wdm items in my Gemfile. I’ll keep the --trace option in mind for the next time I have issues.