Sometimes ${HOSTNAME} = short hostname when it should be the FQDN

[reidsunderland]

This seems to sometimes happen when Sarracenia starts at boot.

A change to the systemd configuration might ensure that Sarra doesn't start up until after whatever service is necessary for determining the FQDN.

Some workarounds could be:

• add an option to refuse to post messages when ${HOSTNAME} is not a valid FQDN. Might be useful on important data pumps.
• periodically check (housekeeping?) if the HOSTNAME is not an FQDN, and try calling socket.getfqdn() again to see if it has updated.

[petersilva]

in the latest versions, there is a "Requires=network-online.target" line in the systemd unit, which is supposed to take care of that... in both versions... if running the latest and greatest. The internet seems to be saying that that should be enough to have dns working before starting up. But the version of v2 is currently limited to a 2021 vintage because an issue with poll overhead.

[reidsunderland]

On ddi we're supposed to be on the latest version, so I assumed that it already had the updated systemd unit. Now that I've checked, we're actually still on 2.22.10p2.

We're using the public ppa and there isn't a newer version available:

# apt-cache madison metpx-sarracenia
metpx-sarracenia | 2.22.10p2~ubuntu22.04.1 | http://ppa.launchpad.net/ssc-hpc-chp-spc/metpx/ubuntu jammy/main amd64 Packages

It looks like a 22.04/Jammy package never got built for the latest version: http://ppa.launchpad.net/ssc-hpc-chp-spc/metpx/ubuntu/pool/main/m/metpx-sarracenia/

[petersilva]

weird... I'll take a look.

[petersilva]

OK found the problem, and a new release is now available. Do we think the problem is that this is likely fixed by system dependency changes:

v2.22.10:
After=network.target local-fs.target remote-fs.target 

v2.23.x:
After=network-online.target local-fs.target remote-fs.target 
Requires=network-online.target

[petersilva]

yes. I think that is correct. So it is already fixed in source, and just need to deploy. but to deploy, need to migrate the polls.

[reidsunderland]

The problem seems to still be happening, even with the updated systemd service file :(

# cat /lib/systemd/system/sarra.service
# This file provides a service definition for sarra
# It is equivalent to a /etc/init.d script when systemd is init system.
# Packager should place this file in: /usr/lib/systemd/system
# user and group 'sarra' need to exist and that account needs to
# contain the configuration for the pump (as per sarra standards)
#

[Unit]
Description=Sarracenia File Copy Service
After=network-online.target local-fs.target remote-fs.target
Requires=network-online.target

[Service]
Type=forking
ExecStart=/usr/bin/sr start
User=sarra
Group=sarra

ExecReload=/usr/bin/sr reload
ExecStop=/usr/bin/sr stop

[Install]
WantedBy=multi-user.target

[petersilva]

This is some kind of host configuration problem. When I look at my PC...

fractal% systemctl --type=target --all | grep nss-
  nss-lookup.target                                                                    loaded    active   active Host and Network Name Lookups
  nss-user-lookup.target                                                               loaded    active   active User and Group Name Lookups
fractal% 

which, I think is correct. but on the ddi servers, these show up as "inactive dead" ...