Git Product home page Git Product logo

Comments (8)

yihui avatar yihui commented on August 27, 2024

I tested my own minimal Jekyll repo, and it worked. I tried to build your site, but it requires a few additional ruby gems that do not seem to be straightforward for me to install...

from servr.

cboettig avatar cboettig commented on August 27, 2024

okay, I can replicate the same problem with your minimal site; I guess a few more details are pertinent.

I'm running inside docker, though not clear why that should cause daemon=TRUE to break when everything else works. You should at least be able to reproduce what I get if you're up for running docker.

The gems are already installed on my image, so inside the repo for your minimal image you can run:

docker run  -v $(pwd):/data -p 8787:8787 -p 4000:4000 -d -u 0 cboettig/labnotebook supervisord

This sets up RStudio on port 8787 and an open port on 4000. It links the current working dir to /data on the container. (-u 0 and supervisord are things to launch rstudio, I should handle these as defaults instead).

I then go into RStudio via http://localhost:8787 (login = rstudio:rstudio). Switch to the /data working dir and everything is dapper when I run:

jeykll::serve(host='0.0.0.0', port=4000)

and your site builds and displays on localhost:4000 as expected. yay. (Note that docker now requires we use that 0.0.0.0 for the external port to work). Try

jeykll::serve(host='0.0.0.0', port=4000, daemon=TRUE)

and the site builds but doesn't display. Weird, eh? Same problem occurs if we try this just on a bash shell on the container (e.g. take RStudio out of the mix). Works fine unless we have daemon=TRUE.

from servr.

cboettig avatar cboettig commented on August 27, 2024

(minor edit to the above: I meant to write that when using daemon=TRUE the site does build as before, but doesn't display on the port, even though no errors appear. Just edited my comment above.)

from servr.

yihui avatar yihui commented on August 27, 2024

If you are using docker, then I'm out of ideas. One thing you need to be careful is not to close the R session: daemon = TRUE relies on the R session; once the R session is closed, the daemonized server will be shut down. I do not quite see what the advantage is to use daemon = TRUE in your case.

from servr.

cboettig avatar cboettig commented on August 27, 2024

Yeah, I realize that; I'm not closing the R session.

My idea is that a user should be able to just open RStudio, render the site by running jekyll() at the RStudio prompt, and then still have a usable RStudio session where they can continue to edit & test the Rmd. This is the advantage of daemon=TRUE. Otherwise one needs to run the jekyll() function from somewhere other than the RStudio instance (e.g. from the terminal). Does that make any sense?

I do this with docker, since as you noted dependencies aren't always a trivial thing, particularly with ruby in the mix.

Guess I'll have to dig deeper into what you're doing with daemon=TRUE; but your source-code looks a bit over my head. Is it possible that daemon=TRUE isn't respecting the host=0.0.0.0 or the port somehow? It looks like the non-daemon approach is doing the same thing as jekyll serve (but maybe I'm wrong), but can't wrap my head around what the daemon approach is doing.

from servr.

yihui avatar yihui commented on August 27, 2024

You can first check if the following minimal httpuv example works:

httpuv::startDaemonizedServer("0.0.0.0", 4000, app = list(
  call = function(req) list(
      status = 200L,
      headers = list(
        'Content-Type' = 'text/html'
      ),
      body = 'Hello World!'
  )
))

If it does not, I guess I won't be able to help.

from servr.

cboettig avatar cboettig commented on August 27, 2024

Ah, thanks for the minimal example, that's helpful. With that I can see that the problem only occurs when run from RStudio, and works just fine outside of RStudio. Since this shows my problem is just related to whatever httpuv is doing and not anything that servr is doing, so I will close this issue and follow up in a more appropriate place. Thanks again for your help debugging and sorry for the trouble!

from servr.

yihui avatar yihui commented on August 27, 2024

No worries. I guess even if you report to the httpuv repo, Joe is unlikely to investigate it soon. The hep page of httpuv::startDaemonizedServer has stated that this function is experimental.

from servr.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.