1. Introduction

The document covers updating from the FS 10.2.0 feature release to the 10.2.1 patch. This patch release fixes five bugs:

  • A crash that could be caused by a very long recorder error? query response in the mk5_status (and fb_status) command. This seemed to be a fairly rare situation. Only one crash has been reported (just recently) in the more than two years this command has existed.

  • A bug in the terminate command that caused the FS to not terminate due to a race condition when (typically) a non-FS process exited. This was typically a fairly benign bug, but could be frustrating because it would be necessary to try the terminate command more than once, possibly a few times, in order to terminate.

  • A bug that prevented use of autoftp on FSl11 (Debian Bullseye) and other systems that require FS python3 support.

  • A bug in the satellite command that caused it to fail after many uses in the same run of the FS.

  • A cosmetic bug in the handling of DBBC3 multicast time when using DDC_V firmware the first time after the FS computer was rebooted and when switching between DDC_V and non-DDC_V (DDC_E/DDC_U) firmware.

These bugs and the fixes are discussed in detail in the FS changes subsection below.

2. Upgrading from 10.2.0 to 10.2.1

To install this update, your current FS version must be FS 10.2.0 (see the FS 10.2 Update Notes document). If you already installed the patch release, 10.2.1, when you installed 10.2, there is nothing more to do; the steps in this document can be skipped.

2.1. Fetch and make the patched version

  1. Update the FS

    There are two options:

    1. If you are using FSL9, FSL10, or another system that supports connections to github, then as prog execute:

      cd /usr2/fs-git
git fetch --tags -q origin 10.2
git checkout -q 10.2.1
make clean rmdoto rmexe all >& /dev/null
make -s

      No output from the last command indicates a successful make.

    2. If you are using FSL8, or otherwise unable to use git or connect to github:

      Please follow all the steps in the Installing from an archive subsection in the Release Model document. Please note that:

      • For FSL8, or if you are otherwise unable to connect to github, you will need the TIP in the wget step.

      • Use 10.2.1 as the value for tag.

      • Be sure to set the link for /usr2/fs by running make install, where that is an option.

3. Changes since 10.2.0

There are separate sub-sections with summaries of changes in the FS and drudg.

Clickable links such as #36 connect to specific issues reported at https://github.com/nvi-inc/fs/issues.

3.1. FS changes

  1. Fix bug in mk5_status (and fb_status) command when handling long recorder error? query responses (closing #234).

    Details

    In the mk5_status (and fb_status) command, if an error? query response was too long to fit in the buffer (256 characters), the basic checks on its format could generate an error. If so, the class number that had been allocated to return previous status? (and possibly other error?) responses would not be passed back to the caller to be processed, leaving the class number in limbo (a class number leak). After about 35+ of these errors there would be no class numbers left and the FS would crash.

    Additionally, the error? response was not reported to the caller preventing it from being displayed for relatively easy identification of the underlying recorder error.

    The cause of the problem was actually more general in nature. Any error in the process of getting the error? response (or in the process of getting a status? response after the first), could also cause a class number leak.

    In addition to fixing these two class number leaks, some other small improvements were made:

    • The buffer size was increased 1024 characters.

    • The error message for an incorrectly formatted status? and error? response was revised to say that it was a format error and that it could have been due to truncation. Previously, it just said there was no reply, which is a different case.

    • The available response when a formatting error is detected is returned to the caller for display.

    • The error number codes of the mk5_status command were moved to an include header to make them accessible in more than one file of code without duplicating them. This was helpful for returning the available response where there was a formatting error.

    • If the command ends with a processing error so that it is not known whether there are remaining recorder errors to process, the error report says there may be errors yet to process, instead of that there are.

    Thanks to Jon Quick (HartRAO) for reporting this bug and testing the fix.

  2. Fix bug in the terminate command (closing #226).

    Details

    Sometimes the terminate command would incorrectly not, in fact, terminate the FS when using the display server. Instead it would give an un    2 (and ultimately a bo -176) error. This happened when the FS was checking to make sure autoftp and fs.prompt weren’t active. Workarounds were:

    • Trying terminate again. More than one try may have been needed.

    • Using terminate=force. That should have worked in all cases (except pfmed being active), but would defeat the check for autoftp and fs.prompt being active. So it had to be used with care.

    This bug was triggered by a process file disappearing from /proc/ after it was found in the directory and before it was opened for reading to see if it was for an instance of autoftp or fs.prompt. There was usually only a very small time window in which this could happen. The code was aware of this case, but there was a bug in how it was handled.

  3. Fix bug in the display server shim for xterm on FSL11, restoring use of autoftp (closing #218).

    Details

    The conversion to python3 for FSL11 (bullseye) missed fsserver/shims/xterm. As a result, it was not possible on FSL11 systems to use autoftp (or sy=xterm …​, which should be avoided anyway). The simple fix for this was to make separate python2 and python3 versions, like the other python scripts in FS 10.2. This bug only occurred for FSL11 systems (and other systems that use FS python3 support).

  4. Fix bug in the satellite=…​ command that prevented temporary TLE files from being closed (closing #220).

    Details

    When cleaning up at the end of processing, satellite=…​ commands were not closing the temporary TLE files. As a result, if many of the commands were used in a single invocation of the FS, the limit on the number of open files could be reached, causing subsequent satellite=…​ commands to fail. This situation could happen, e.g., if many of the commands were used sequentially to approximate continuous tracking.

    Thanks to Jamie McCallum and David Schunck (both at Hobart) for finding this, reporting it, and providing the fix.

  5. Fix bug in reporting time from DBBC3 multicast (closing #224).

    Details

    This was a mostly cosmetic (but pretty unsightly) bug that occurred in certain situations. For DDC_V firmware, which does not have multicast time, it caused spurious times to be displayed. While for non-DDC_V (DDC_E/DDC_U) firmware, which does have time available, it caused the time to be suppressed. This was due to an error in FS initialization in 10.2.0. The two situations where the bug occurred were:

    • When using only DDC_V firmware, the first time the FS was run after rebooting.

    • When switching between DDC_V firmware and a non-DDC_V firmware (DDC_E/DDC_U), in either direction, the first time the FS was run after the change in equip.ctl.

    This bug did not occur if only non-DDC_V firmware was used.

    There was a fairly simple workaround for this bug. It was to terminate and restart the FS before using it, after:

    • A reboot, when only using DDC_V firmware

    • Changing equip.ctl, when switching between DDC_V firmware and a non-DDC_V firmware (DDC_E/DDC_U), in either direction.

    Thanks to J. Quick (HartRAO) for reporting this bug.

3.2. drudg changes

There are no drudg changes.