Interactive apps launching with wrong host

We’re currently running into an odd issue where apps aren’t launching with the correct hostname.

The output.log for Jupyter for instance lists the following:

[I 2025-05-05 10:41:06.653 ServerApp] Jupyter Server 2.14.2 is running at:
[I 2025-05-05 10:41:06.653 ServerApp] http://n01:6808/node/n01.cm.cluster/6808/lab
[I 2025-05-05 10:41:06.653 ServerApp]     http://127.0.0.1:6808/node/n01.cm.cluster/6808/lab
[I 2025-05-05 10:41:06.653 ServerApp] Use Control-C to stop this server and shut down all kernels (twice to skip confirmation).
[W 2025-05-05 10:41:06.657 ServerApp] No web browser found: Error('could not locate runnable browser').
[I 2025-05-05 10:41:06.668 ServerApp] Skipped non-installed server(s): bash-language-server, dockerfile-language-server-nodejs, javascript-typescript-langserver, jedi-language-server, julia-language-server, pyright, python-language-server, python-lsp-server, r-languageserver, sql-language-server, texlab, typescript-language-server, unified-language-server, vscode-css-languageserver-bin, vscode-html-languageserver-bin, vscode-json-languageserver-bin, yaml-language-server
Discovered server listening on port 6808!
Generating connection YAML file...

However, http://n01:6808 should say http://n01.<sitename>.edu:6808 instead. I can verify that manually accessing the url with http://n01.<sitename>.edu:6808 works fine.

This happens on every app, not just Jupyter.

Any help figuring this out is appreciated.

I’m sure it has something to do with /etc/resolve.conf and how your hostnames are being generated as just the shortname instead of the FQDN.

I tried to find the source code for where this is, but it’s too buried for me to find how exactly they come to that hostname, but I’m sure it’s out of the python’s socket library which is pretty low level.

Changing host=$(hostname) in the cluster yml doesn’t change the hostname either. All it does is modify the n01.cm.cluster portion.

If you run a script like this on a compute node, what does it return? The FQDN or the simple name?

#!/usr/bin/env python3

import socket

print(socket.gethostname())

It gives the short name, so n01 instead of n01.<sitename>

Seems like it’s an issue with your compute nodes more than OnDemand. Also, the /etc/hosts file is another file you’ll need to reference.

Here’s a stackexchange question I found that may be helpful.

https://unix.stackexchange.com/questions/530064/dnsdomainname-and-hostname-f-does-not-return-fqdn

Of course this seems like it’s an issue on your systems which may require a larger change that you may not want to accommodate. There’s no configuration in OnDemand that can change this - this is related to how you’re compute nodes are networked.

As to the issue with OnDemand - does it affect the applications if they boot with the short name? Do you have issues with OnDemand because you’re not using the FQDN?

I will note that I had similar issues in reverse, and you can tinker with the hostname command in your clusters.d/name.yml

Example that fixes to use only shortname and fixes some capitalization weirdness from a DNS upgrade that wasn’t propagating at expected speed.

set_host: "host=$(hostname | awk -F. '{print $1}' | tr A-Z a-z )"

You could try

set_host: "host=$(hostname -f | tr A-Z a-z )"

which should give the full name and then lowercase it.