FS 10.2 to Latest Commit Update Notes

There are two situations in which local code will need to be updated:

If the if=schedule:none…​ command is used to determine that no schedule is active, the :none will need to be removed and the true and false commands swapped. Additionally, embedded spaces are no longer supported and a second colon, :, is now considered part of the schedule name.

Add the following to postob in the station procedure library:

A script, /usr2/fs/misc/rxgfix4, has been provided for this. If the original version of the affected comments have been preserved, they will be updated to the new form. Only the comments immediately before the active T_cal entries will be updated.

Execute:

If the script stops because there are existing .bak files, you can delete them, if it is safe to do so, by adding the -d option (see /usr2/fs/misc/rxgfix4 -h for the details) to the command before the files to be updated. If it is not safe to delete them, you could, for example, rename them to end in .bak2 with rename 's/.bak$/.bak2/' *.rxg.bak first. The rename command, by default, will not overwrite existing files, but you might want to check that your new ending is not already in use for some .rxg backup files to avoid possibly mixing different “generations” of backups.

Execute the commands for all the shells that you use, typically just your login shell:

You will need to exit any active shell (including possibly logging out and back and in again) to make the aliases active.

You may also wish to make these changes for prog (and any AUID accounts).

To install this script, execute:

If you are using a remote connection and would like to open a new window to run the FS (or client) in, comment out the “normal” if clause and uncomment the command for a new window. In either case, if you use AUID accounts, you must promote to oper before running the script.

The updated /usr2/fs/misc/ntp.txt file describes the new form and how to install the needed scripts, all in sections 6a and 6e. Please use those directions as a guide if you want to update.

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:

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.

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.

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.

For legacy calibration, it is necessary to hold the gains fixed during a scan so that sampled TPI values can be related to the most recent T_sys measurement. At the end of the scan, the gains should be released to seek an appropriate level for the next scan. For the DBBC(2), this is done by the next mode setup. However for the DBBC3, setup_proc keyword in skedf.ctl is normally used to suppress the setup procedure for most scans. Instead, the gains can be released in postob.

To accomplish this, the following was added to the example postob for DBBC3:

The same addition was also made for DDBC(2) since it is benign and the setup_proc keyword might be used.

The updated example files in /usr2/fs/st.default/proc/ are d3fbstation.prc, dstation.prc, dfbstation.prc, and d5cstation.prc.

Thanks to Christian Plötz (Wettzell) for pointing out that this was missing and Beppe Maccaferri (Medicina) for confirming the fix.

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:

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:

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

When the selected rack type is not rdbe it doesn’t make sense to process multicast messages from RDBEs. Before, this was only disabled if no RDBEs were defined in the rdbc<x>.ctl control files. Doing that was necessary to avoid error messages if the RDBEs were not transmitting multicast for some reason. However, having to remove the definitions when RDBEs were not in use makes it cumbersome to switch between RDBEs and other rack types. Additionally, not having the RDBEs defined disables any access to RDBEs, specifically with the rdbe= and rdbex= low-level device communication commands. Traditionally for flexibility, the FS has allowed low-level communication with devices that were not selected.

Thanks to Javi González-García (Yebes) for reporting this oversight.

Previously when using RDBE detectors with onoff, the LOs being valid was only tested for when setting up onoff (onoff=…​) for all detectors. It was not tested for other detector selections. It is only necessary that the LOs be valid when onoff is started (onoff) and all selected detectors should be checked. That is also the time when the LO and other channel information is collected. This supports changing the configuration of the channels after onoff is setup, which is consistent with how other racks are handled.

The MA -104 error is a warning that there may be a 30 second delay while a possible serial line error is worked around at the start-up of matcn. The value of an argument in the call to report the error had a value of -4 instead of, the correct value, 0.

The display server requires at least two processors (cores) to operate properly. The issue occurs in server termination. Occasionally, termination occurs normally even when there is only one processor.

Typically this problem only occurs if the FS is being run in a virtual machine with only one processor. Virtual machines can usually be reconfigured to have more processors.

It should be possible to make it work with one processor, but that hasn’t been implemented yet. Until then, if there is only one processor available, warning messages (with hints about what to do) are printed at FS startup and when restarting fails because apparently a previous instance of the server failed to terminate.

Thanks to Christian Plötz (Wettzell), Uwe Bach (Effelsberg) and Javi González-García (Yebes) for reporting this issue. Thanks to David Horsley (Hobart) for diagnosing the cause when it was first reported (issue #178).

Normally, the fivept and onoff commands are used to collect pointing and antenna sensitivity data, respectively. This requires some sort of signal chain and detector device. The latter is usually in the back-end rack. If no detector is available, or doesn’t produce useful radiometry data, it is now possible to exercise/test the antenna with acquire by using device none in the fivept and onoff setup commands. In this case, there will be no detector interaction.

Sample procedure library file st.default/proc/point_no_det.prc and control file st.default/control/ctlpo_no_det.ctl are provided as examples for using none as detector. They are mentioned in the help pages for fivept and onoff as a reminder.

Including the emails in the log avoids having to enter comments from the email messages a second time to get them into the log.

When originally written (by Jason Soohoo, Haystack Observatory), the program that became rdbemsg did not run on FS computers and could not easily add comments to the log. Due to on oversight when the program was ported to FS computers, adding the email message to the log, as msg does, was not added. This has been corrected for both the python2 and python3 versions of rdbemsg.

Thanks to the staff at KPGO for reporting this issue.

The popen program is used to log the output of Linux programs. A -p option was added to replace the #popen# string at the start of log entries with / (the logging system inserts the /). This makes the log entries look like the output of internal FS commands. Its use is not necessary and is not recommended in most circumstances. However, it does look better, particularly for replacements of internal FS commands line wx. Information on using the popen program can be found from help=sy.

Thanks to J. Quick (HartRAO) for conceiving, and providing an implementation, of this change,

The removal of the -b option in FS 10.2.0 was a bit too hasty. The long form of the option was --background, which suggested that it was the inverse of --foreground. This was not the case. With the server enabled, it started the FS without a client. This might be convenient to use for starting the FS from a script or otherwise without the log being displayed on the terminal. A pitfall of using it is that there is no feedback about the whether the FS started correctly or had a start-up error and aborted. As a result, this option must be used with caution.

To make it clearer that it does not start the client, the short option was changed to -C (not client) and the long option to --no-client. The help output now includes a warning about the lack of feedback for startup errors.

Thanks to Christian Kristukat (AGGO) for reporting the loss of functionality when the -b option was removed. Thanks to Beppe Maccaferri (Medicina) for pointing out the possible pitfall.

This prevents these example files being used accidentally with values that are incorrect for a new installation. Instead, the pointing analysis programs and/or antcn (while reading the default mdlpo.ctl) will fail until the files have been setup with (hopefully reasonable) values for the antenna. While this may make the first time use for a new antenna a little painful, it is better than having incorrect values being used.

In FSL11, the make install command would fail if the source directory was not owned by root. While this situation would not normally occur, it could if the make install was executed a second time after an initial installation. This might happen, for example, if make install were used to reset the /usr2/fs link. The failure occurred because of a confluence of two issues: (i) git was unnecessarily used to determine the version of the FS with the install target and (ii) the version of git in FSL11, and probably later versions, will throw an error if the directory is not owned by the user. The problem was resolved by removing the use of git to determine the FS version for make install.

Thanks to Jon Quick (HartRAO) for reporting this issue.

Two further enhancement were made:

The FS is a user application. It is risky, and a potential security issue, to run it as root. In particular, the sy=…​ command, if misused either accidentally or on purpose, could cause serious damage. To avoid this, the FS startup program, fs, the server, fsserver, and the client program, fsclient, will refuse to run if the user is root. This is not strictly necessary for the client, but it was included for consistency. Off-line utilities, including pfmed, can still be run by root, but this is not recommended and should be avoided. It may lead to problems. However, it would not be inherently dangerous.

Two new shell aliases were added:

This utility can be found in misc/fsy. It can installed in ~oper/bin. It will check to see if the client can be run (i.e. FS is running and display server is enabled). If not, it will start the FS. It can be useful for systems using the display server to start the FS if it is not already running or the client if it is. There is some risk associated with this since you will not get obvious feedback if the FS is not running and you expect it to be. However, you may prefer to not have to enter a separate command to run the FS if attempting to start the client (fslcient) first fails.

The script includes commented out commands that you can use instead if you prefer to open a new window to run the FS or client in. This may be useful for some remote connections.

Thanks to Chevo Terrazas (MGO) for pointing out the overall usefulness of this script, which was originally only provided as a site-specific ad hoc tool.

New scripts, grep_ntpq, cname_ntpq_ip, and redact_ntpq_ip were added to simplify (i.e., make more readable and easier to maintain) the check_ntp SNAP procedure. The updated /usr2/fs/misc/ntp.txt file describes the new form and how to install the new scripts, all in sections 6a and 6e.

Previously when no schedule and schedule procedure library was in use, none was displayed as the name in the output of the schedule and proc commands, respectively. Also, in pfmed's preamble, the current FS schedule procedure library was shown as none. This came about because the FS used none internally when there was no active file. This was inconsistent and could be confusing because none was also an allowed name for schedules and schedule procedure libraries. This was corrected by making the following changes:

The consequences of these changes for existing FS installations is fairly limited. It seems unlikely they will affect anyone, but to be complete, they are listed here:

The positive outcome of all this is that the schedule and schedule procedure library names are now handled consistently. The use of none is not recommended for either since that may be confusing, but the behavior will now be clearer and predictable.

The comments in the example .rxg files (/usr2/fs/st.default/control/rxg_files/*.rxg) had not kept up with the expansion of the size of the T_cal table, first from 400 entries to 600 and then 1200. The files have now been updated.

A script, /usr2/fs/misc/rxgfix4, has been provided for optional use to update the working .rxg files at station. If the original version of the comments, with 400, have been preserved, they will be updated to the new form. Only the comments immediately before the active T_cal entries will be updated. Lines that list 100 and 600 as the maximum will also be updated. The former was apparently the size in some preliminary versions before the first official release (9.6.9, September 2003, commit 7c26ea900dee19b01958e5c4ad846b89d64638c5) that supported .rxg files. The latter was never provided as an example, but is covered just in case. See /usr2/fs/misc/rxgfix4 -h for the details.

A few ASCII files had non-ASCII characters in them.