doesn't seem to happen all the time though (e.g. the previous login of that test run was fine). most peculiar
Doesn't seem to actually do anything negative, simply fails to show the update message in the MOTD
options: remove motd feature (may actually be good from a network use pov) OR debug why it sometimes fails and fix
The results of the motd check are cached, which may be why it's hard to reproduce because the second call probably would use the no-update-found cached result (which was produced by being unable to connect to releases.neon). I think removing the feature is not called for here given it is cached, which leaves us with debugging why it goes wrong. That may or may not be easier to do knowing that results are cached. I've also had a quick look at the actual checker code and I can't see it setting a short time, so its probably not a http timeout that is the problem here.
Motd calls /usr/lib/ubuntu-release-upgrader/release-upgrade-motd which looks for stamp file /var/lib/ubuntu-release-upgrader/release-upgrade-available if it exists it will simply be printed again (assuming it isn't too old), if it is not it is *always* created by running /usr/lib/ubuntu-release-upgrader/check-new-release. The outcome of check-new-release may be 'Failed to connect to HOST... Check your Internet connection or proxy settings'. This will always be the case if the user logged into a login shell with motd before internet access is available (e.g. before network.target is reached by switching to a getty super early [sddm startup is not waiting for network.target], or when on a laptop before the wifi is connected). The error will then be reported until the stamp gets too old and gets refreshed. Nothing much to be done IMO as the code involved is just a bit daft. Ideally it probably shouldn't record an error but an empty stamp so there is effectively no output instead of silly output. From a neon POV what we could do is possibly disable the motd as its arguably garbage and delaying (first) login a bit due to network IO.