http server fails silently, likely stray host key in environment not caught by run-options

[genovese]

I have a number of older luminus apps that run fine, but this week I created a couple new ones with the latest framework (for which the generated code is different than in the older apps) and none of them ran, even with the simplest setup. No error message or other problem indication was given. I tracked it to http-server, which logged that it had started but was not working, and I got it to work by passing a map with explicit keys from env. I realized then that HOST was set in my environment (for various reasons and not as a server host) and this was getting passed unchanged through luminus.http-server/run-options, causing problems.

I realize that I can remove the HOST environment variable before running the server, but this seems less convenient and turn-key than I think luminus wants to be. Perhaps HOST could be treated like PATH when luminus mounts the various components. For instance, the :host option to http-server/start could be changed to something like :server-host with run-options changed accordingly:

(defn run-options [opts]
  (merge
    {:host "0.0.0.0"}
    (-> opts
        ;;options contain ENV path and possibly host
        ;;Immutant path is found at :handler-path
        ;;Server host is found at :server-host
        (dissoc :path :contexts :host)
        (rename-keys {:handler-path :path, :server-host :host})
        (select-keys
          (-> #'immutant/run meta :valid-options)))))

Just a thought. Thanks.

[yogthos]

The PATH is a standard environment variable that typically refers to the system paths. As far as I know the HOST variable doesn't have a standard meaning, so changing it to SERVER_HOST could potentially affect another user who might have that variable set. Since :host is the key that's already used by all the HTTP servers I'd rather not change it.

[yogthos]

Also, there should be an error in the log regarding this, e.g:

[2016-05-10 15:28:31,733][ERROR][luminus.http-server] server failed to start on port 3000
java.lang.RuntimeException: java.net.UnknownHostException: foo: unknown error
...

[genovese]

Sounds reasonable. What threw me is that I did not set HOST; it's being set automatically somewhere (?) to the host mapped to my machine on the university wireless network. I'm not sure yet where this is happening, and I assumed it might be replicated elsewhere. But it does appear an odd feature of our setup. So you're right about HOST.

On the other hand, the problem does not appear in the logs. For instance:

-=[mesgs started successfully using the development profile]=-
[2016-05-10 10:56:29,956][INFO][luminus.http-server] starting HTTP

server on port 3000 [2016-05-10 10:56:30,007][INFO][org.xnio] XNIO version 3.4.0.Beta1 [2016-05-10 10:56:30,089][INFO][org.xnio.nio] XNIO NIO Implementation Version 3.4.0.Beta1 [2016-05-10 10:56:30,169][INFO][org.projectodd.wunderboss.web.Web] Registered web context / [2016-05-10 10:56:30,172][INFO][luminus.repl-server] starting nREPL server on port 7000 [2016-05-10 10:56:30,196][INFO][mesgs.core] #'mesgs.config/env started [2016-05-10 10:56:30,196][INFO][mesgs.core] #'mesgs.handler/init-app started [2016-05-10 10:56:30,196][INFO][mesgs.core] #'mesgs.core/http-server started [2016-05-10 10:56:30,196][INFO][mesgs.core] #'mesgs.core/repl-server started

The hostname is technically valid, but the server is not accessible and the app does not run.

It might be worth putting a note in the documentation string for start (or somewhere else appropriate) to beware of environment variables that conflict with immutant options.

Thanks, Chris

On Tue, May 10, 2016 at 3:29 PM, Dmitri Sotnikov notifications@github.com wrote:

Also, there should be an error in the log regarding this, e.g:

[2016-05-10 15:28:31,733][ERROR][luminus.http-server] server failed to start on port 3000 java.lang.RuntimeException: java.net.UnknownHostException: foo: unknown error ...

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/luminus-framework/luminus-immutant/issues/1#issuecomment-218264764

[yogthos]

Yeah, I this it's the first report I've seen for this problem.

[genovese]

It's tcsh which sets HOST automatically. So in principle others could encounter this.

(I've been meaning to switch fully to zsh for a long time, and now I have another reason.)

On Tue, May 10, 2016 at 8:34 PM, Dmitri Sotnikov notifications@github.com wrote:

Yeah, I this it's the first report I've seen for this problem.

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/luminus-framework/luminus-immutant/issues/1#issuecomment-218331654

[yogthos]

Ah interesting, it does actually seem to set HOST to the hostname. So, if your hostname is correctly configured, then it is the correct variable. For example, here's what I end up with:

[myapp]─> tcsh
[Yogthoss-MBP:myapp] yogthos% echo $HOST
Yogthoss-MBP
[Yogthoss-MBP:myapp] yogthos% lein run
[2016-05-10 21:29:24,709][INFO][myapp.env]
-=[myapp started successfully using the development profile]=-
[2016-05-10 21:29:24,715][INFO][luminus.http-server] starting HTTP server on port 3000
[2016-05-10 21:29:24,897][INFO][luminus.repl-server] starting nREPL server on port 7000
[2016-05-10 21:29:24,924][INFO][myapp.core] #'myapp.config/env started
[2016-05-10 21:29:24,924][INFO][myapp.core] #'myapp.handler/init-app started
[2016-05-10 21:29:24,924][INFO][myapp.core] #'myapp.handler/log started
[2016-05-10 21:29:24,925][INFO][myapp.core] #'myapp.core/http-server started
[2016-05-10 21:29:24,925][INFO][myapp.core] #'myapp.core/repl-server started

[genovese]

That's what I expected as well. On the system at work, HOST is set to the dynamically generated ``hostname'' assigned on the wireless network rather than that configured on the machine. I thought it should still work, as the hostname is valid, but it hangs. I'll investigate further tomorrow to see if there is some other mismatch that is causing it to hang. Thanks.

On Tue, May 10, 2016 at 9:30 PM, Dmitri Sotnikov notifications@github.com wrote:

Ah interesting, it does actually seem to set HOST to the hostname. So, if your hostname is correctly configured, then it is the correct variable. For example, here's what I end up with:

[myapp]─> tcsh [Yogthoss-MBP:myapp] yogthos% echo $HOST Yogthoss-MBP [Yogthoss-MBP:myapp] yogthos% lein run [2016-05-10 21:29:24,709][INFO][myapp.env] -=[myapp started successfully using the development profile]=- [2016-05-10 21:29:24,715][INFO][luminus.http-server] starting HTTP server on port 3000 [2016-05-10 21:29:24,897][INFO][luminus.repl-server] starting nREPL server on port 7000 [2016-05-10 21:29:24,924][INFO][myapp.core] #'myapp.config/env started [2016-05-10 21:29:24,924][INFO][myapp.core] #'myapp.handler/init-app started [2016-05-10 21:29:24,924][INFO][myapp.core] #'myapp.handler/log started [2016-05-10 21:29:24,925][INFO][myapp.core] #'myapp.core/http-server started [2016-05-10 21:29:24,925][INFO][myapp.core] #'myapp.core/repl-server started

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/luminus-framework/luminus-immutant/issues/1#issuecomment-218339093

[yogthos]

Sounds good, would be nice to know what exactly is causing this. Another thing to not is that the HTTP server defaults to using 0.0.0.0 for listening, so if the external interface can't be bound then it'll fail as well.