The following outlines high-level troubleshooting to resolve the DHCP Service from re-setting the hostname:
1. Modify /usr/share/google/set-hostname and set the hostname in the metadataThis script is only called during boot time and ensures the hostname is the one needed.
It will not however prevent the system for changing the hostname after x hours.
Calling this script every minute and change back the hostname to the short version once is detects it has been changed, helps but it's not 100% proof perfect as the WDOG process can identify the hostname change within the minute it is changed back and shutdown the database.
Setting the hostname to the long version before starting the database causes semaphore errors and the database not to start. This is due to various defects with 'long hostnames, long uname -srvn)
SYSTEM ERROR: Unable to semAdd semaphore set : semid = -(, errno = 43. (10839)
2. Create a DHCP exit hook to reset the hostname. DHCP hooks didn't work for this Centos 7.1 version.
This was the advice provided by Google Services. 3. Trigger a hostname change with a NetworkManager dispatcher script. When a DHCP request comes in to change the hostname, the script kicks in quickly change the hostname back.
The following script
example could be improved as it currently triggers on all network events and should only be used for DHCP requests:
## script /etc/NetworkManager/dispatcher.d/12-force-hostname
#!/bin/bash
#
# DHCP Hook to reset the hostname to the shortname to prevent Progress database errors
#
new_host_name=$(curl --fail --silent http://metadata/computeMetadata/v1/instance/attributes/hostname -H "Metadata-Flavor: Google")
echo "$(date) NetworkManager: set hostname to $new_host_name" >> /var/log/hostname.log
hostname
${new_host_name%%.*}
Reference: Storing and Retrieving Instance Metadata https://cloud.google.com/compute/docs/storing-retrieving-metadata#default
