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 [email protected]
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
#1 (comment)

[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 [email protected]
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
#1 (comment)

[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 [email protected]
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
#1 (comment)

[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.