HOSTNAME reverting to darkstar on boot

mfoley · 10-01-2017, 10:42 PM

Here's something interesting I've not noticed before. When my Linux 14.2 server boots, I have rc.local send me an email with the subject "$HOSTNAME^^} Reboot". Today, I received that message after booting, after doing a `slackpkg upgrade-all`. I got the message with the subject, "DARKSTAR Reboot".

When I logged in to check it, it had the correct $HOSTNAME. Is this something new with the latest update or have I just never noticed that before?

If the latter (not noticed), why? Is rc.local running before network connections are established and/or DHCP assigns the IP?

Note that this host's name is not in /etc/hosts, although it is in /etc/HOSTNAME. It is a DHCP client and the DHCP server assigns the IP; and, presumably, the host name? I'm gussing that rc.local is running before all that is accomplished. This is just a guess on my part. If some Slackster expert could confirm or correct this notion, I'd be grateful.

rworkman · 10-01-2017, 11:58 PM

First, rc.local is run at the end of rc.M, so all of the network stuff will have already run at that point. However, it is certainly possible that your dhcp server is slow to respond and thus the network is not yet (fully?) configured.

As to the system hostname being set via dhcp, that should not occur in a default Slackware setup. If you have the desired hostname in /etc/HOSTNAME (it should be in the format of "hostname.localnet.tld"), then this happens early-ish in rc.M:

Code:

# Set the hostname.
if [ -r /etc/HOSTNAME ]; then
  /bin/hostname $(cat /etc/HOSTNAME | cut -f1 -d .)
else
  # fall back on this old default:
  echo "darkstar.example.net" > /etc/HOSTNAME
  /bin/hostname darkstar
fi

In other words, if the system is getting the "darkstar" hostname assigned to it, then either /etc/HOSTNAME is not readable by root or "darkstar" is what's in /etc/HOSTNAME :-)

Re setting hostname via dhcp, I'm not familiar with how dhclient handles this, but if you are using dhcpcd as the dhcp client (you are unless you changed that or didn't install dhcpcd), then it should only set a hostname if one isn't set at all (i.e. current value is unset/null/blank or is "localhost") OR if /etc/dhcpcd.conf has "force_hostname" set to yes/true/whatever (you would have had to add this, as that parameter isn't even present in the default config file).

In short, I have no idea how you're seeing that behavior if none of the above information can explain it.

GazL · 10-02-2017, 03:54 AM

Just a guess, but..

$HOSTNAME is an internal bash variable initialised when the bash shell starts. rc.local gets sourced into rc.M, so $HOSTNAME during rc.local will be whatever was set at the shell invocation of rc.M (before /etc/HOSTNAME is read).

One workaround might be to reset $HOSTNAME in rc.M after /etc/HOSTNAME is used, but as I've mentioned before in the requests for current thread, I really dislike all the sourcing that goes on in rc.S/M and would rather just have all the child scripts in rc.d exec'd according to their #! specifiers, avoiding these sorts of issues.

mfoley · 10-02-2017, 11:18 AM

rworkman: my /etc/HOSTNAME is readable by root and, in fact, world. And if it could not, rc.M would write "darkstar.example.net" to /etc/HOSTNAME, which it does not. My actual, correct FDQN is in /etc/HOSTNAME.

GazL: I think you might be on to something. Yes, rc.local is sourced by rc.M and no, HOSTNAME is not set anyway in rc.M. So, perhaps this has always worked this way and I've just never noticed. I think the solution will be to set HOSTNAME in rc.local as:

Code:

export HOSTNAME=`hostname`

That should get the setting made by rc.M (3rd line of rworkman's snippet).