This is a problem by itself, but more so if fsclient is run as a child of itself as in the default stpgm currently:

This results in two windows being opened for every window managed by fsserver. (This was frustrating to track down!)

Such uses cases my be better covered by using ssub directly anyway, especially once #25 is merged.

This prevents, for example. the .snp file from working as is for a BB test with no recorder.

This can probably be fixed with something like:

+++ b/drudg/snap.f
@@ -1091,7 +1091,7 @@ C prior to this scan. Do only on a new pass for continuous.
               call snap_disk2file_abort(lufile)
               kdisk2file_prev=.false.
             endif  
-            if(km6disk) then
+            if(cstrack(istn).eq."BB") then
               csetup_name="setupbb"
             else
               call setup_name(ccode(icod),csetup_name)

After a successful make, when doing a check 'make' to see if there are any problems, we get some extraneous output that might cloud the issue:

make -C oprin
make[1]: Entering directory '/usr2/fs-10.0.0-alpha2-11-g352e0da7/oprin'
../include.mk:97: warning: overriding recipe for target 'clean'
Makefile:59: warning: ignoring old recipe for target 'clean'
make[1]: '../bin/oprin' is up to date.

oprin does work

While investigating #22, it became clear that the output display and logging for the TNX command uses logit(), creating a risk of a possible deadlock.

Background: The TNX functionality was added in 08249d9 (2001 Feb). In 54af15c (2016 Jul), ddout was fixed to not use class I/O with fserr, sterp, and erchk to eliminate the risk of a deadlock in high log entry volume situations, like multicast logging. However TNX use of logit() and reporting error bo -999 (also usinglogit())were apparently overlooked; they are still vulnerable to this. Probably only cls_snd() was looked for.

Still, the chance of a deadlock is pretty low. It could probably only happen in a high volume situation (active multicast logging) if the operator either uses TNX or changes to an existing log file big enough to cause a warning about its size (bo -999). Even then it is probably unlikely that the class I/O system would be at maximum capacity.

It looks like the most straightforward way to fix this in ddout.c is probably:

• make a C version of logen.f to format the log entry, only a subset is needed; it is probably easiest to start with logit.c, use of which would be replaced for this purpose
• add a C function to output the entry to the screen and the log; only a subset of the full, ddout functionality is needed; the same error checking/reporting for the disk writing is needed; these two C functions might be combined into one
• use a a direct log entry error message approach, like with logite.c, to format errors and then output, both accomplished using the above C function(s) in place of logit()
• change these errors in fserr.ctl to be placeholders ('this is a place holder for an error in ddout.c') to avoid accidental reuse

The particular bo errors reported by ddout would probably forego being filtered by TNX and sent to sterp and erchk, but with more code rearrange probably could be fully supported.

There is no make dependency on the VERSION/RELEASE information. So the information in the executables could be stale. Possible solutions:

1. Brute force delete the affected .o files on every top level make

2. Save VERSION/RELEASE information in a file and if different (or missing) apply (1).

3. Write rules for the affected .o files that will cause them to be remade when the condition in (2) is met instead of using (1),

From #45:

07:29:44?ERROR fm -1 Opening file: /usr2/proc/nothing.prc
07:29:44?ERROR bo -133 Error opening procedure library, UNIX 2: No such
file or directory

Added in a2f6bbc, while removing a non-logged error message when used with the FS, i.e., in a program that is "online". This was being conservative to avoid a silent error in case the caller did not handle the error. In fact, everywhere it is used in a FS online (i.e. not stand-alone), the error is logged normally, except aquir, where it could be fixed up easily (there are lots of other non-logged fmpsee/ errors though). In the case of aquir, this was a by-product of how it was incompletely promoted from an external to an internal FS program in 1ae556d. I can remember both of those errors, but finding them in the history with blame was relatively easy; especially since the second was apparently more about 25 years ago.

If the snap command given to inject_snap generates an error, the code to print the message back to the user hits an error eg:

$ inject_snap -w blag
cls_chk: illegal class number 0 pid 25020
cls_chk error 1 in cls_rcv()

Seen on both 32 and 64bit FSL10.

For example, running

help=(

Causes a segfault in fsclient or boss, depending on running with fs server or not:

23:16:14;help=(
sh: 1: Syntax error: "(" unexpected
sh: 1: Syntax error: "(" unexpected

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
...
boss terminated-Segmentation violation

This was the underlying problem in #3.

The shell use allows some pretty trivial remote execution. While it's not security issue right now as we "trust" user input, it might be good to fix this if we want to change model in the future.

In a similar vein, there's also a buffer overrun error here that should be fixed.

Actually it is /usr2/tle_files

FS10 seems to ship equip.ctl with the default lines

* DBBC3 firmware version, bbcs/if, ifs
  v223 16 8

According to the Hat-Lab hompage, https://www.hat-lab.cloud/downloads-dbbc3-ddc/, the available firmwares are: 121, 123 (mostly used by e.g. Onsala so far in VGOS obs), 124 (should be 123 with multicast; see #32 ), 125 (experimental)

Therefore I was puzzled by the "223" in the default equip.ctl. Should it perhaps be 123? Also, which firmware versions are currently supported by the FS; is this listed somewhere?

It would be nice to have a facility to suppress metserver (and maybe metclient) error e-mails when their is a known problem, e.g., the device is disconnected, without having to disable it. That way it could recover automatically when it comes back on line.

There might be something fancier that would be better, but a simple approach might be have a file in /usr2/control that the daemon reads. If it doesn't exist, processing is normal. If it does exist, it has a time limit/epoch for how long to suppress the e-mails, including options for indefinitely and until it recovers. Maybe deleting the file would be a simple way for the operator to restore it immediately.

On May 4, 2020, at 9:33 PM, Alexander Neidhardt wrote:

RN -401
Command not supported for VLBA2/VLBA42.
exists twice

There are some lines with just one " instead of two quotes "". Made it more difficult to parse the file.

On May 12, 2020, at 3:42 AM, @jfhquick wrote:

If you issue a proc=nothing where there is no such procedure file, you get
the error messages you'd expect:

07:29:44?ERROR fm -1 Opening file: /usr2/proc/nothing.prc
07:29:44?ERROR bo -133 Error opening procedure library, UNIX 2: No such
file or directory

but the unexpected (buggy) side effect is that it invalidates the currently
loaded procedure file which IMHO it should not have.

This causes a conflict between 32- and 64-bit operation in fixed length data structures in C and values passed to FORTRAN. This will need to be fully resolved before 2038, only 19 years away.

Short term:

• A change in declarations of passed in pointers in rtelb from time_t to int and changes to pass pointers to int to the same routines (and then conversion of results to time_t) in fmset is probably sufficient for now. This is implemented. It needs to be tested in setcl and fmset for:

• 5B

• RDBE

• FiLa10G

• Mark IV

• S2 (no longer possible)

• VLBA (no longer possible)

• Use of the rtelb routines in FORTRAN needs to be checked.

Longer term:

• The use of the int array centisec in dbbcn, rdbcn, mk5cn, (other...cn?), fmset, and setcl (and chekr?) and perhaps others can probably be easily rewritten to use a structure with time_t in C code.

• The use in FORTRAN code will be tricker since there needs to be integer4 and integer8 for 32- and 64-bit respectively, and that will also affect the data structure lay-out. Are FORTRAN structures an option?

• In principle for model computer there is no need to have the time since boot limited to 248 days. For 64-bit systems this limit will be expanded beyond being a practical constraint (248 days already seemed long enough for that), but maybe the time code could be restructured to avoid this even on 32-bit systems. Maybe struct timeval could be used internally instead of clock_t to represent ticks, but that seems excessive Maybe a 64-bit int is good enough. There is a related issue #56.

Similar to #48, fsclient with the "-n" flag will still create fs.prompt.

This case is slightly more complex however. In principle you could be in a situation with only one fsclient with the "-n" flag set and a blocking "fs.prompt" is called, in which case the client would give no indication as to why the FS has stopped.

Perhaps such a situation is unlikely enough that the right thing to do is ignore it and honour "-n" anyway.

It looks like an "anonymous" method is available with ftp-ssl:

https://cddis.nasa.gov/Data_and_Derived_Products/CDDIS_Archive_Access.html

Which might be a good idea to minimize dependence on a .netrc file in case some sites can't use that.

This (benign) error also occurred on all three systems at Wz right after the year change. The FS at Onsala, at least, had been running since summer.

Note from the attached log (where is it?) that this error was not for the first procedure executed, exper_initi, typically from the schedule procedure library, but for sched_initi and clock procedure, typically in the station procedure library. If the field system had not been restarted since the new year, the already open procedure libraries have the previous year’s timestamps. The station library would have been in that state. The log was opened after the year change. The check for a century wrap in newpr.f is not restrictive enough and moved the procedure last log time into the next century, past the 2038 signed 32-bit limit, hence the error:

 if(itpr(6).lt.mod(itmlog(6),100)) then
    itpr(6)=itpr(6)+(itmlog(6)/100+1)*100
 else
    itpr(6)=itpr(6)+itmlog(6)-mod(itmlog(6),100)
 endif

Tightening up that if test, should fix it (testing should prove it). OTOH, reseting the procedure time-stamps when a new log is opened should also fix it. The former is probably better.

We probably haven’t hit this case before (or heard about it) since most people probably don’t leave the FS running across the year boundary (once upon a time it was not supported) or they were too busy to report it when it went away after a restart (which resets the procedure timestamps).

On Jan 8, 2020, at 6:42 AM, Eskil Varenius @varenius wrote:

Hello Ed,

I hope you had a nice Christmas and New years. I have an FS error question. Earlier this week, when started a schedule I got this error on the OTT-FS machines:

2020.007.10:04:13.90?ERROR bo -257 Internal error: time for prsecs invalid

After restarting the FS the problem seems gone, but I have never seen this before. Could you explain what "prsecs" is, and perhaps any clue to why this error appeared? I haven't managed to track it down to a specific command causing it, but if it happens again it may be useful to know a bit more.

Sometimes a monit program will be started in a window of the wrong size (the user should perhaps edit X resources for a more permanent fix) and resizing does not help.

The monit programs should respond to SIGWINCH and redo their init function.

The day 248 time problem reared its head at WSRT without warning as reported by Richard Blaauw (and subsequently by Jon Quick for HartRAO). This turned out to be because the errors/warning were not enabled if the time model is computer.

This goes back to traced back to commit f3ee6ea, FS 9.11.0, Jan 23, 2013 , code change made 2012/05/25.

After a few e-mails with Richard, we identified the lack of warning being due to the code incorrectly only reporting the error if the model is not computer. In principle there is no limitation if the model is computer, which is why it was not checked. However it should have been checked since the same internal 32-bit logic as for non-computer models is used for tracking the computer time, for now. Lesson learned: it must always be checked. Related issue #15 discusses the long term solution.

RIchard's initial report:

On Jun 29, 2020, at 6:07 AM, Richard Blaauw <> wrote:

Hello Ed, 

I hope you are doing well. 

Our Fieldsystem 9.13.02 went back in time to 2019 this happened during a project. See attached log at 2020.178.22:08:38.39.

I am a bit puzzled why it jumped to 2019. 

- time.ctl is set to computer.  ( so that means it should get the time from the system the fieldsystem runs on?)

Fieldsystem1:/usr2/control/:> less time.ctl
*     rate (seconds/day)   span (hours)   model (none/offset/rate)
         0.000                1.000       computer
- system time is correct: 

Fieldsystem1:/usr2/control/:> date
Mon Jun 29 09:49:50 UTC 2020

It has 3 ntp servers. 

Fieldsystem1:/usr2/control/:> ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================
+chime2.surfnet. .MRS.            1 u   63 1024  377    8.066    0.079   0.124
*wsrtntp.nfra.nl .MRS.            1 u  599 1024  377    0.270   -0.040   0.030
 ntp1.nl.uu.net  .GPS.            1 u  36d 1024    0    3.996   -0.173   0.000

- fmset nothing is running there I dont see a time. Its also stuck doesnt respond on any keys + / s /S or esc. ( see attached screenshot)
- monitw also gives the 2019 time. ( see attached screenshot)

I am sure if I restart the fieldsystem software the time will jump back to the future 2020. 
Have you seen this before? Where is the fieldsystem software getting the time from?

Relevant snippet from the log he attached:

2020.178.22:08:38.39#tpicd#tpi/ib,989.18
2019.046.19:41:00.44#tpicd#tpi/1l,14572,1u,10870,2l,11705,2u,11753,3l,11878,3u,11972,4l,13886,4u,11894

Sometimes schedules aren't available on CDDIS, but are on others.

Maybe the support for other data centers could be à la plog.

I tried running ONOFF with cont_cal=on. Doing this on the 9.12.12 system works, I think because the relevant procedures are defined as

define  caloffnf      20128155358
caloff
sy=go onoff &
!+1s
sy=go onoff &
enddef
define  calonnf       20128155406
calon
sy=go onoff &
!+1s
sy=go onoff &
enddef

However, following the recommendations in "/usr2/fs-git/help/onoff.___" , I have now (for FS10) defined these as

define  calonnf       20171074921
if=cont_cal,,calon
!+1s
sy=rte_go onoff &
enddef
define  caloffnf      20171074911x
if=cont_cal,,caloff
!+1s
sy=rte_go onoff &
enddef

I don't remember the logic for the IF statements (is this documented somewhere?), i.e. which call is excecuted if true/false.

I assume from the behaviour in dc6.log that with cont_cal enabled, I don't get any useful tcal signal for the DBBC3. Likely the work in #32 needs to be finished first? Assuming this is the case, I turned cont_cal=off and tried again. Indeed, I now get reasonable values, see attached dc7.log. Should I get reasonable values also with cont_cal enabled? Perhaps I am missing something somewhere?

fsserver currently needs some /var/run directories to create unix sockets to
comminucate with client. fsalloc creates them and sets the group owner to rtx
and permissions for group read and write.

While the group rtx is used on standard on FSL, it may not exists on other less
supported systems. This will result in fsalloc failing.

Ultimatly I plan to move fssever to use just a single TCP socket which will
remove the need for the directories.

It would be useful to publish the log messages on fsserver too. This will require some code in ddout.

merge branch is based on 9.13.0 and 9.12.13. Changes from 9.13.1 are finalized and need to be merged

Issue: When using fesh to download a schedule, and that schedule already exists on the computer, the error/warning fesh returns contains a typo.

The current return is (____ is path and the schedule file);
"____ exits, delete or use '-f' to get fresh schedule"
where it should state
"____ exists, delete or use '-f' to get fresh schedule"

FWVersion: 10.0.0-alpha2-57-G10396864 and 10.0.0-alpha2-58-g229f696e (20m and 12m respectively)
OSVersion: FSL10
Station: KPGO 20m and 12m

Before I forget:

Jon was using 9.13.2.

On Oct 29, 2019, at 3:05 AM, @jfhquick wrote:

Hi Ed

There's something slightly fishy with TNX. A source set before the end of
an experiment so I turned the 'fl -1' error off and subsequently switched to a
new schedule. Then I got the following curious behaviour when trying to
turn it back on again:

21:11:04;tnx=f1,-1,on
21:11:04?ERROR bo -304 This error has not occured yet, so it can't be turned 'on'.
21:11:13;tnx
21:11:13/tnx/fl,-1,off,#1,Previous source in this schedule not reached before new source was commanded
06:33:17;tnx=
06:33:17?ERROR bo -300 There must be two character error mnemonic for TNX.
06:33:23;tnx=fl
06:33:23?ERROR bo -301 Error decoding error number in TNX.
06:33:28;tnx=fl,-1
06:33:28?ERROR bo -312 Error already "off", for TNX.
06:33:34;tnx=fl,-1,on
06:33:50;tnx
06:33:50/tnx/disabled

And, no the error did not occur in the interim. Logically one should be able to turn an error back on if it appears in the TNX list even if it hasn't yet occurred in the context of the current schedule. What intrigues me most is that initially it wouldn't let me but, after thinking about all night, then
it would! Actually I suspect it was trying to turn it off again that 'fixed' it.

Most of the uses of FS libraries use implicit function declarations, which might be hiding some sleeping bugs --- especially with 64 bit conversion.

A better approach would be to make header files with the function declarations/prototypes and include them when needed. A tool like cproto could help generate the header files from what we currently have. This will also clean up some of those pesky compiler warnings!

We would need to decide how we should structure/arrange the headers. Some options:

• Throw it all in one huge header say include/clib.h, etc.
• or split them up into more logical groups, say include/dbbc.h (maybe these can be merged with the struct definitions that are already there)
• or perhaps something in between... Say start with monolithic and slowly move towards the second.

This is a cul-de-sac of 64bit development that comes off of 9.12.12 used at MGO and at AuScope that could be added to the FS history. Since it has been used in operations, perhaps it should be added.

See https://github.com/dehorsley/fs/blob/73a1578dda7117568d4c4b2342bdcdcac35c137d/misc/refresh_secondary.sdb_efi#L10

It seems grub-install assumes the mounted /boot/efi partition is the one you want to install to, so this line doesn't do anything. Should replace with

check /dev/sda1 is mounted as /boot/efi, then:

grub-install /dev/sda
update-grub
cp /dev/sda1 /dev/sdb1

Entering "help" or "help=", causes a "help=(null)" to be sent to fsclient and then fsclient crashes.

Two things need to be fixed here:

• "(null)" should not be sent
• fsclient should gracefully handle helpstr_ erroring like that

Reported by Jun Yang at Onsala.

Thinking out loud ...

So sometimes it is necessary to do development on an operational system. However, you don't want to disturb the repo that is actively being used for operations. Is there a well accepted way to do that?

One possibility is to clone the repo that is being for operations to another local repo for development, pushing to the operational repo for testing (this is assuming you don't want/need to change the link to the repo and reboot to re-initialized shared memory). This gives a way to stage changes and make sure they compile before trying to run them. I have tried that and it seems to work fine.

However, another possibility is to make the development repo the clone of the github repo and make the operational repo a clone of that. This would allow staging changes from the github repo as well without affecting the operational repo. You would pull to the operational system to do the testing.

In either case, you are still disturbing the operation system. but only when testing is possible and if the development is on a new branch the operational system should be restored with checkout - and make.

Maybe it is just better to have a separate repo, a clone of the operational repo, change the link, and reboot. Then you would only push when it is ready for operations. Changing the link and rebooting (twice) is a lot of overhead though.

Are there other/better possibilities? Maybe the above options are ungood git thinking. :)

Using commit fbd0133 :
The ONOFF VAL and SIG lines appar OK, but others have a spurious char inserted after #onoff#, for example:

2020.171.07:34:20.63#onoff#ðAPR ih     9552.00 1.573  371.67  0.027000 1.00000  0.027000 11600.00 p 0.16620
[...]
2020.171.07:36:07.12#onoff#¶ONSC   104.0   0.00000   0.00000 ig     2399.0      1.4 ih     2570.0      4.2

Is this correct? Please see attached logfile dc6.log. Again, it doesn't happen for the VAL or SIG lines, but for the others.

Some field misalignments, particular the third, do not produce visible errors. This can make commands appear to be unavailable. This is particular bad for stcmd.ctl since when it will be obvious at a station why local commands have disappered. A problem like this is more likely to be caught in fscmd.ctl since FS testing before a release should reveal it.

Previously discussed via email, see below.

On Oct 1, 2019, at 3:31 AM, Eskil Varenius wrote:

currently the OSO FS reports lcp, rcp also for the VGOS tels. But they really have hor/ver. Do you know where I should change to specify this, in the rxg file? I've just used the lcp/rcp for now to keep things simple, it's just a labeling thing anyway. But would be nice to get it right.

On 2019-10-01 10:15, Himwich, Ed (GSFC-61A.0)[NVI INC] wrote:

yes of course, but it is somewhat down the priority list. For now, we use the “usual” convention that polarizations are in alphabetical order (in English) for any given polarization scheme.
Type pol 1 pol 2
----- ————— ———
linear horizontal vertical
CP left right
?? X Y
It is a kludge, but it works well enough for now. At some point I suppose we might get a type where this won't work anymore. Then we will have to bite the bullet, if haven’t already fixed it by then.

I still think this is a low-prio issue, but noting it here so it's not forgotten. I assume the pols "X/Y" can/should be used for VGOS-like systems observing in linear polarisation (but hor/ver could perhaps also work).

Only FS items that are needed are lnfch.a and vex.a

• Make it work in FS environment
• Pare down f95 options to minimum
• Make it also work on John's sked environment

For the third one, an idea is to set an environment variable for FS prog account that the Makefile (and code) can use to decide if it is on a FS computer, if not use then use what the sked environment needs.

Depending on the skedf.ctl set-up, drudg may want to prompt interactively, currently for tpicd interval and continuous cal control when making .prc files.

Maybe there is some way to pass those "unexpected" prompts to the user for an answer (expect?).

Maybe fesh could have command line options to set those responses or to allow the .prc dialogue to be interactive or something better ...

I am brave (or foolish) enough to try the latest master-branch, i.e.

oper@njord:/usr2/fs-git$ git rev-parse HEAD
68e69f45353a8d7166b446070fa553ef136829ca

at my FS test machine in Onsala. In general it seems fine, but when I tried "ONOFF" the FS just died on me:

2020.170.06:41:23.30&exper_initi/" Configure fivept and onoff
2020.170.06:41:23.30&exper_initi/" for system checks
2020.170.06:41:23.30&exper_initi/fivept=azel,-2,9,0.4,1,057u
2020.170.06:41:23.30&exper_initi/onoff=2,2,,,,,all
[...]
2020.170.06:42:54.51;onoff
2020.170.06:43:00.44#onoff#?    De      Center  TCal    Flux    DPFU     Gain    Product   LO    T   FWHM
2020.170.06:43:00.44#onoff#?APR 001l   3464.40 1.713  842.82  0.027000 1.00000  0.027000     0.00 p 0.45825
2020.170.06:43:00.44#onoff#?APR 002l   3432.40 1.709  848.90  0.027000 1.00000  0.027000     0.00 p 0.46252
2020.170.06:43:00.44#onoff#?APR 003l   3368.40 2.042  861.36  0.027000 1.00000  0.027000     0.00 p 0.47131
2020.170.06:43:00.44#onoff#?APR 004l   3304.40 2.203  874.24  0.027000 1.00000  0.027000     0.00 p 0.48044
2020.170.06:43:00.44#onoff#?APR 005l   3208.40 1.986  894.39  0.027000 1.00000  0.027000     0.00 p 0.49481
2020.170.06:43:00.44#onoff#?APR 006l   3080.40 1.986  922.95  0.027000 1.00000  0.027000     0.00 p 0.51537
2020.170.06:43:00.44#onoff#?APR 007l   3048.40 1.986  930.41  0.027000 1.00000  0.027000     0.00 p 0.52078
2020.170.06:43:00.44#onoff#?APR 008l   3016.40 1.986  938.02  0.027000 1.00000  0.027000     0.00 p 0.52631
2020.170.06:43:00.44#onoff#?APR 009l   3464.40 2.635  842.82  0.027000 1.00000  0.027000     0.00 p 0.45825
2020.170.06:43:00.44#onoff#?APR 010l   3432.40 2.636  848.90  0.027000 1.00000  0.027000     0.00 p 0.46252
2020.170.06:43:00.44#onoff#?APR 011l   3368.40 2.970  861.36  0.027000 1.00000  0.027000     0.00 p 0.47131
2020.170.06:43:00.44#onoff#?APR 012l   3304.40 4.240  874.24  0.027000 1.00000  0.027000     0.00 p 0.48044
2020.170.06:43:00.44#onoff#?APR 013l   3208.40 4.934  894.39  0.027000 1.00000  0.027000     0.00 p 0.49481
2020.170.06:43:00.44#onoff#?APR 014l   3080.40 4.934  922.95  0.027000 1.00000  0.027000     0.00 p 0.51537
2020.170.06:43:00.44#onoff#?APR 015l   3048.40 4.934  930.41  0.027000 1.00000  0.027000     0.00 p 0.52078
2020.170.06:43:00.44#onoff#?APR 016l   3016.40 4.934  938.02  0.027000 1.00000  0.027000     0.00 p 0.52631
2020.170.06:43:00.44#onoff#?APR 017l   5736.40 2.680  567.24  0.027000 1.00000  0.027000  7700.00 p 0.27675
2020.170.06:43:00.44#onoff#?APR 018l   5704.40 2.688  569.78  0.027000 1.00000  0.027000  7700.00 p 0.27830
2020.170.06:43:00.44#onoff#?APR 019l   5640.40 2.401  574.94  0.027000 1.00000  0.027000  7700.00 p 0.28146
2020.170.06:43:00.44#onoff#?APR 020l   5576.40 2.238  580.20  0.027000 1.00000  0.027000  7700.00 p 0.28469
2020.170.06:43:00.44#onoff#?APR 021l   5480.40 2.035  588.29  0.027000 1.00000  0.027000  7700.00 p 0.28968
2020.170.06:43:00.44#onoff#?APR 022l   5352.40 1.789  599.45  0.027000 1.00000  0.027000  7700.00 p 0.29661
2020.170.06:43:00.44#onoff#?APR 023l   5320.40 1.853  602.32  0.027000 1.00000  0.027000  7700.00 p 0.29839
2020.170.06:43:00.44#onoff#?APR 024l   5288.40 1.877  605.21  0.027000 1.00000  0.027000  7700.00 p 0.30020
2020.170.06:43:00.44#onoff#?APR 025l   5736.40 3.119  567.24  0.027000 1.00000  0.027000  7700.00 p 0.27675
2020.170.06:43:00.44#onoff#?APR 026l   5704.40 2.983  569.78  0.027000 1.00000  0.027000  7700.00 p 0.27830
2020.170.06:43:00.44#onoff#?APR 027l   5640.40 2.620  574.94  0.027000 1.00000  0.027000  7700.00 p 0.28146
2020.170.06:43:00.44#onoff#?APR 028l   5576.40 2.397  580.20  0.027000 1.00000  0.027000  7700.00 p 0.28469
2020.170.06:43:00.44#onoff#?APR 029l   5480.40 2.084  588.29  0.027000 1.00000  0.027000  7700.00 p 0.28968
2020.170.06:43:00.44#onoff#?APR 030l   5352.40 1.731  599.45  0.027000 1.00000  0.027000  7700.00 p 0.29661
2020.170.06:43:00.44#onoff#?APR 031l   5320.40 1.742  602.32  0.027000 1.00000  0.027000  7700.00 p 0.29839
2020.170.06:43:00.44#onoff#?APR 032l   5288.40 1.692  605.21  0.027000 1.00000  0.027000  7700.00 p 0.30020
2020.170.06:43:00.44#onoff#?APR 033l   6856.40 0.977  491.12  0.027000 1.00000  0.027000  7700.00 p 0.23154
2020.170.06:43:00.44#onoff#?APR 034l   6824.40 1.060  493.00  0.027000 1.00000  0.027000  7700.00 p 0.23263
2020.170.06:43:00.44#onoff#?APR 035l   6760.40 1.310  496.80  0.027000 1.00000  0.027000  7700.00 p 0.23483
2020.170.06:43:00.44#onoff#?APR 036l   6696.40 1.283  500.67  0.027000 1.00000  0.027000  7700.00 p 0.23708
2020.170.06:43:00.44#onoff#?APR 037l   6600.40 1.522  506.58  0.027000 1.00000  0.027000  7700.00 p 0.24052
2020.170.06:43:00.44#onoff#?APR 038l   6472.40 1.682  514.70  0.027000 1.00000  0.027000  7700.00 p 0.24528
2020.170.06:43:00.44#onoff#?APR 039l   6440.40 1.672  516.77  0.027000 1.00000  0.027000  7700.00 p 0.24650
2020.170.06:43:00.44#onoff#?APR 040l   6408.40 1.739  518.86  0.027000 1.00000  0.027000  7700.00 p 0.24773
2020.170.06:43:00.44#onoff#?APR 041l   6856.40 1.391  491.12  0.027000 1.00000  0.027000  7700.00 p 0.23154
2020.170.06:43:00.44#onoff#?APR 042l   6824.40 1.430  493.00  0.027000 1.00000  0.027000  7700.00 p 0.23263
2020.170.06:43:00.44#onoff#?APR 043l   6760.40 1.518  496.80  0.027000 1.00000  0.027000  7700.00 p 0.23483
2020.170.06:43:00.44#onoff#?APR 044l   6696.40 1.504  500.67  0.027000 1.00000  0.027000  7700.00 p 0.23708
2020.170.06:43:00.44#onoff#?APR 045l   6600.40 1.862  506.58  0.027000 1.00000  0.027000  7700.00 p 0.24052
2020.170.06:43:00.44#onoff#?APR 046l   6472.40 1.772  514.70  0.027000 1.00000  0.027000  7700.00 p 0.24528
2020.170.06:43:00.44#onoff#?APR 047l   6440.40 1.769  516.77  0.027000 1.00000  0.027000  7700.00 p 0.24650
2020.170.06:43:00.44#onoff#?APR 048l   6408.40 1.779  518.86  0.027000 1.00000  0.027000  7700.00 p 0.24773
2020.170.06:43:00.44#onoff#?APR 049l  10696.40 1.651  336.36  0.027000 1.00000  0.027000 11600.00 p 0.14842
2020.170.06:43:00.44#onoff#?APR 050l  10664.40 1.624  337.26  0.027000 1.00000  0.027000 11600.00 p 0.14887
2020.170.06:43:00.44#onoff#?APR 051l  10600.40 1.502  339.08  0.027000 1.00000  0.027000 11600.00 p 0.14976
2020.170.06:43:00.44#onoff#?APR 052l  10536.40 1.516  340.92  0.027000 1.00000  0.027000 11600.00 p 0.15067
2020.170.06:43:00.44#onoff#?APR 053l  10440.40 1.578  343.72  0.027000 1.00000  0.027000 11600.00 p 0.15206
2020.170.06:43:00.44#onoff#?APR 054l  10312.40 1.540  347.50  0.027000 1.00000  0.027000 11600.00 p 0.15395
2020.170.06:43:00.44#onoff#?APR 055l  10280.40 1.504  348.46  0.027000 1.00000  0.027000 11600.00 p 0.15443
2020.170.06:43:00.44#onoff#?APR 056l  10248.40 1.299  349.43  0.027000 1.00000  0.027000 11600.00 p 0.15491
2020.170.06:43:00.44#onoff#?APR 057l  10696.40 2.011  336.36  0.027000 1.00000  0.027000 11600.00 p 0.14842
2020.170.06:43:00.44#onoff#?APR 058l  10664.40 1.931  337.26  0.027000 1.00000  0.027000 11600.00 p 0.14887
2020.170.06:43:00.44#onoff#?APR 059l  10600.40 1.541  339.08  0.027000 1.00000  0.027000 11600.00 p 0.14976
2020.170.06:43:00.44#onoff#?APR 060l  10536.40 1.632  340.92  0.027000 1.00000  0.027000 11600.00 p 0.15067
2020.170.06:43:00.44#onoff#?APR 061l  10440.40 1.903  343.72  0.027000 1.00000  0.027000 11600.00 p 0.15206
2020.170.06:43:00.44#onoff#?APR 062l  10312.40 1.968  347.50  0.027000 1.00000  0.027000 11600.00 p 0.15395
2020.170.06:43:00.44#onoff#?APR 063l  10280.40 1.844  348.46  0.027000 1.00000  0.027000 11600.00 p 0.15443
2020.170.06:43:00.44#onoff#?APR 064l  10248.40 1.676  349.43  0.027000 1.00000  0.027000 11600.00 p 0.15491
2020.170.06:43:00.44#onoff#?APR 001u   3496.40 1.681  836.84  0.027000 1.00000  0.027000     0.00 p 0.45405
2020.170.06:43:00.44#onoff#?APR 002u   3464.40 1.713  842.82  0.027000 1.00000  0.027000     0.00 p 0.45825
2020.170.06:43:00.44#onoff#?APR 003u   3400.40 2.079  855.08  0.027000 1.00000  0.027000     0.00 p 0.46687
2020.170.06:43:00.44#onoff#?APR 004u   3336.40 2.160  867.74  0.027000 1.00000  0.027000     0.00 p 0.47583
2020.170.06:43:00.44#onoff#?APR 005u   3240.40 1.829  887.56  0.027000 1.00000  0.027000     0.00 p 0.48993
2020.170.06:43:00.44#onoff#?APR 006u   3112.40 1.986  915.62  0.027000 1.00000  0.027000     0.00 p 0.51007
2020.170.06:43:00.44#onoff#?APR 007u   3080.40 1.986  922.95  0.027000 1.00000  0.027000     0.00 p 0.51537
2020.170.06:43:00.44#onoff#?APR 008u   3048.40 1.986  930.41  0.027000 1.00000  0.027000     0.00 p 0.52078
2020.170.06:43:00.44#onoff#?APR 009u   3496.40 2.588  836.84  0.027000 1.00000  0.027000     0.00 p 0.45405
2020.170.06:43:00.44#onoff#?APR 010u   3464.40 2.635  842.82  0.027000 1.00000  0.027000     0.00 p 0.45825
2020.170.06:43:00.44#onoff#?APR 011u   3400.40 3.331  855.08  0.027000 1.00000  0.027000     0.00 p 0.46687
2020.170.06:43:00.44#onoff#?APR 012u   3336.40 4.680  867.74  0.027000 1.00000  0.027000     0.00 p 0.47583
2020.170.06:43:00.44#onoff#?APR 013u   3240.40 4.872  887.56  0.027000 1.00000  0.027000     0.00 p 0.48993
2020.170.06:43:00.44#onoff#?APR 014u   3112.40 4.934  915.62  0.027000 1.00000  0.027000     0.00 p 0.51007
2020.170.06:43:00.44#onoff#?APR 015u   3080.40 4.934  922.95  0.027000 1.00000  0.027000     0.00 p 0.51537
2020.170.06:43:00.44#onoff#?APR 016u   3048.40 4.934  930.41  0.027000 1.00000  0.027000     0.00 p 0.52078
2020.170.06:43:00.44#onoff#?APR 017u   5704.40 2.688  569.78  0.027000 1.00000  0.027000  7700.00 p 0.27830
2020.170.06:43:00.44#onoff#?APR 018u   5672.40 2.699  572.35  0.027000 1.00000  0.027000  7700.00 p 0.27987
2020.170.06:43:00.44#onoff#?APR 019u   5608.40 2.553  577.56  0.027000 1.00000  0.027000  7700.00 p 0.28307
2020.170.06:43:00.44#onoff#?APR 020u   5544.40 2.343  582.87  0.027000 1.00000  0.027000  7700.00 p 0.28634
2020.170.06:43:00.44#onoff#?APR 021u   5448.40 2.087  591.04  0.027000 1.00000  0.027000  7700.00 p 0.29138
2020.170.06:43:00.44#onoff#?APR 022u   5320.40 1.853  602.32  0.027000 1.00000  0.027000  7700.00 p 0.29839
2020.170.06:43:00.44#onoff#?APR 023u   5288.40 1.877  605.21  0.027000 1.00000  0.027000  7700.00 p 0.30020
2020.170.06:43:00.44#onoff#?APR 024u   5256.40 1.870  608.13  0.027000 1.00000  0.027000  7700.00 p 0.30202
2020.170.06:43:00.44#onoff#?APR 025u   5704.40 2.983  569.78  0.027000 1.00000  0.027000  7700.00 p 0.27830
2020.170.06:43:00.44#onoff#?APR 026u   5672.40 3.126  572.35  0.027000 1.00000  0.027000  7700.00 p 0.27987
2020.170.06:43:00.44#onoff#?APR 027u   5608.40 2.792  577.56  0.027000 1.00000  0.027000  7700.00 p 0.28307
2020.170.06:43:00.44#onoff#?APR 028u   5544.40 2.569  582.87  0.027000 1.00000  0.027000  7700.00 p 0.28634
2020.170.06:43:00.44#onoff#?APR 029u   5448.40 2.159  591.04  0.027000 1.00000  0.027000  7700.00 p 0.29138
2020.170.06:43:00.44#onoff#?APR 030u   5320.40 1.742  602.32  0.027000 1.00000  0.027000  7700.00 p 0.29839
2020.170.06:43:00.44#onoff#?APR 031u   5288.40 1.692  605.21  0.027000 1.00000  0.027000  7700.00 p 0.30020
2020.170.06:43:00.44#onoff#?APR 032u   5256.40 1.653  608.13  0.027000 1.00000  0.027000  7700.00 p 0.30202
2020.170.06:43:00.44#onoff#?APR 033u   6824.40 1.060  493.00  0.027000 1.00000  0.027000  7700.00 p 0.23263
2020.170.06:43:00.44#onoff#?APR 034u   6792.40 0.996  494.89  0.027000 1.00000  0.027000  7700.00 p 0.23373
2020.170.06:43:00.44#onoff#?APR 035u   6728.40 1.214  498.72  0.027000 1.00000  0.027000  7700.00 p 0.23595
2020.170.06:43:00.44#onoff#?APR 036u   6664.40 1.291  502.62  0.027000 1.00000  0.027000  7700.00 p 0.23821
2020.170.06:43:00.44#onoff#?APR 037u   6568.40 1.493  508.59  0.027000 1.00000  0.027000  7700.00 p 0.24170
2020.170.06:43:00.44#onoff#?APR 038u   6440.40 1.672  516.77  0.027000 1.00000  0.027000  7700.00 p 0.24650
2020.170.06:43:00.44#onoff#?APR 039u   6408.40 1.739  518.86  0.027000 1.00000  0.027000  7700.00 p 0.24773
2020.170.06:43:00.44#onoff#?APR 040u   6376.40 1.777  520.97  0.027000 1.00000  0.027000  7700.00 p 0.24897
2020.170.06:43:00.44#onoff#?APR 041u   6824.40 1.430  493.00  0.027000 1.00000  0.027000  7700.00 p 0.23263
2020.170.06:43:00.44#onoff#?APR 042u   6792.40 1.409  494.89  0.027000 1.00000  0.027000  7700.00 p 0.23373
2020.170.06:43:00.44#onoff#?APR 043u   6728.40 1.521  498.72  0.027000 1.00000  0.027000  7700.00 p 0.23595
2020.170.06:43:00.44#onoff#?APR 044u   6664.40 1.527  502.62  0.027000 1.00000  0.027000  7700.00 p 0.23821
2020.170.06:43:00.44#onoff#?APR 045u   6568.40 1.821  508.59  0.027000 1.00000  0.027000  7700.00 p 0.24170
2020.170.06:43:00.44#onoff#?APR 046u   6440.40 1.769  516.77  0.027000 1.00000  0.027000  7700.00 p 0.24650
2020.170.06:43:00.44#onoff#?APR 047u   6408.40 1.779  518.86  0.027000 1.00000  0.027000  7700.00 p 0.24773
2020.170.06:43:00.44#onoff#?APR 048u   6376.40 1.848  520.97  0.027000 1.00000  0.027000  7700.00 p 0.24897
2020.170.06:43:00.44#onoff#?APR 049u  10664.40 1.624  337.26  0.027000 1.00000  0.027000 11600.00 p 0.14887
2020.170.06:43:00.44#onoff#?APR 050u  10632.40 1.674  338.17  0.027000 1.00000  0.027000 11600.00 p 0.14931
2020.170.06:43:00.44#onoff#?APR 051u  10568.40 1.617  340.00  0.027000 1.00000  0.027000 11600.00 p 0.15022
2020.170.06:43:00.44#onoff#?APR 052u  10504.40 1.473  341.85  0.027000 1.00000  0.027000 11600.00 p 0.15113
2020.170.06:43:00.44#onoff#?APR 053u  10408.40 1.612  344.66  0.027000 1.00000  0.027000 11600.00 p 0.15253
2020.170.06:43:00.44#onoff#?APR 054u  10280.40 1.504  348.46  0.027000 1.00000  0.027000 11600.00 p 0.15443
2020.170.06:43:00.44#onoff#?APR 055u  10248.40 1.299  349.43  0.027000 1.00000  0.027000 11600.00 p 0.15491
2020.170.06:43:00.44#onoff#?APR 056u  10216.40 1.294  350.40  0.027000 1.00000  0.027000 11600.00 p 0.15539
2020.170.06:43:00.44#onoff#?APR 057u  10664.40 1.931  337.26  0.027000 1.00000  0.027000 11600.00 p 0.14887
2020.170.06:43:00.44#onoff#?APR 058u  10632.40 2.013  338.17  0.027000 1.00000  0.027000 11600.00 p 0.14931
2020.170.06:43:00.44#onoff#?APR 059u  10568.40 1.666  340.00  0.027000 1.00000  0.027000 11600.00 p 0.15022
2020.170.06:43:00.44#onoff#?APR 060u  10504.40 1.538  341.85  0.027000 1.00000  0.027000 11600.00 p 0.15113
2020.170.06:43:00.44#onoff#?APR 061u  10408.40 1.920  344.66  0.027000 1.00000  0.027000 11600.00 p 0.15253
2020.170.06:43:00.44#onoff#?APR 062u  10280.40 1.844  348.46  0.027000 1.00000  0.027000 11600.00 p 0.15443
2020.170.06:43:00.44#onoff#?APR 063u  10248.40 1.676  349.43  0.027000 1.00000  0.027000 11600.00 p 0.15491
2020.170.06:43:00.44#onoff#?APR 064u  10216.40 1.618  350.40  0.027000 1.00000  0.027000 11600.00 p 0.15539
2020.170.06:43:00.44#onoff#?APR ia     2048.00 1.986 1262.73  0.027000 1.00000  0.027000     0.00 p 0.77517
2020.170.06:43:00.44#onoff#?APR ib     2048.00 4.934 1262.73  0.027000 1.00000  0.027000     0.00 p 0.77517
2020.170.06:43:00.44#onoff#?APR ic     5652.00 2.029  574.00  0.027000 1.00000  0.027000  7700.00 p 0.28088
2020.170.06:43:00.44#onoff#?APR id     5652.00 1.822  574.00  0.027000 1.00000  0.027000  7700.00 p 0.28088
2020.170.06:43:00.44#onoff#?APR ie     5652.00 2.029  574.00  0.027000 1.00000  0.027000  7700.00 p 0.28088
2020.170.06:43:00.44#onoff#?APR if     5652.00 1.822  574.00  0.027000 1.00000  0.027000  7700.00 p 0.28088
2020.170.06:43:00.44#onoff#?APR ig     9552.00 1.231  371.68  0.027000 1.00000  0.027000 11600.00 p 0.16620
2020.170.06:43:00.44#onoff#?APR ih     9552.00 1.573  371.68  0.027000 1.00000  0.027000 11600.00 p 0.16620
2020.170.06:43:01.57;caloffnf
2020.170.06:43:01.57&caloffnf/if=cont_cal,,caloff
2020.170.06:43:01.57&caloffnf/!+1s
2020.170.06:43:01.57&caloffnf/sy=rte_go onoff &
2020.170.06:43:01.57&caloff/sy=popen 'noise_force 0 2>&1' -n noise
2020.170.06:43:01.61#popen#noise/!cal_noise_force=0:0;
2020.170.06:43:03.61#popen#noise/Set noise_force 0
2020.170.06:43:04.63#onoff#ORIG 24181.6   0.00000   0.00000   0.00000   0.00000   0.00000   0.00000
cls_chk: class 32 not allocated
cls_chk error 1 in cls_rcv()
onoff terminated-Exit code 255
ddout terminated
fserr terminated
[...]

I might very well be missing some file/configuration/procedure, but I cannot figure out where to start looking. Any ideas?

The main obstacle here is that the user can't pick an arbitrary start time on the target day. However, it would still be useful in some cases to simply rotate a short schedule to a different day.

One sometimes gets warnings about modified holog/MASK/... or holog/mask/... files when checking out old versions. Are they benign? Is there a way to fix that?

Perhaps the group "operators" can run a "send_usr2" command which does the sending tar etc. EG,

on fs1:

visudo

Then edit to add:

%operators ALL=(ALL) NOPASSWD: /usr/local/bin/send_usr2

This allows operators to run that command as root without having to enter a password

On fs2:

visudo

Then edit to add:

%operators ALL=(ALL) NOPASSWD: /usr/local/bin/receive_usr2
%operators ALL=(ALL): /usr/local/bin/refresh_spare_usr2

In refresh_spare_usr2:

ssh fs1 sudo send_us2 | sudo receive_usr2

with

send_usr2 (on fs1):

#!/bin/bash
cd /usr2; tar --one-file-system -cf - .

receive_usr2 (on fs2 with correct /dev/…; also in check if mounted)

fuser -k -m /usr2
umount /usr2
mkfs.ext4 -U $(tune2fs -l /dev/md2 | grep UUID | grep -o '[^ ]*$') /dev/md2
mount /usr2
cd /usr2
tar xpf -

all instead of:

ssh root@mauka "(cd /usr2; tar --one-file-system -cf - .)" | (cd /usr2; tar xpf -)

For VGOS observations using DBBC3, and in particular for source-structure interpretation of the correlated data, we need (continuous) logging of tsys values to a log file during observations.

@wehimwich informed me via email 2019-10-01 regarding this that:

Continuous cal worked, but the communication required overloaded the system. It will have to wait until [DBBC3] multicast is available.

Yesterday I read in an email from Gino Tuccari (DBBC3 developer) that

[multicast is] available the v124 V version, which produces multicast strings and it's just like the version v123 in terms of firmware. [...] I don't think it's compatible one-to-one with the RDBE multicast, because we developed independently, but I suppose this could in some way compared or adapted for the FS.

I have asked Gino if there is an interface document etc. to describe the structure of the multicast. Hopefully the community can work together to adapt the FS10 to parse the DBBC3 multicast in a way similar to the RDBE.

Example:

2019.273.17:00:27.78#onoff#VAL casa        54.9 52.4 ib   2 r   2048.00 1.2754 138.1 4499.4 358.971  1.14
2019.273.17:00:27.78#onoff#VAL casa        54.9 52.4 ic   3 l   5652.00 1.3641 163.3 5580.9 186.725  1.20
2019.273.17:00:27.78#onoff#VAL casa        54.9 52.4 id   4 r   5652.00 0.8811 57.21 1656.0 131.741  1.01
2019.273.17:00:27.78#onoff#VAL casa        54.9 52.4 ie   5 l   5652.00 1.3114 118.4 3953.0 182.325  1.17
2019.273.17:00:27.78#onoff#VAL casa        54.9 52.4 if   6 r   5652.00 0.9347 58.57 1700.0 132.096  1.02
2019.273.17:00:27.78#onoff#VAL casa        54.9 52.4 ig   7 l   9552.00 1.0767 73.18 2223.0 140.555  1.06
2019.273.17:00:27.78#onoff#VAL casa        54.9 52.4 ih   8 r   9552.00 0.9882 63.13 1715.5 155.888  0.95
2019.273.17:00:27.78#onoff#    source       Az   El  De   I P   Center   Comp   Tsys  SEFD  Tcal(j) Tcal(r)

This was reported by Eskil Varenius at Onsala

To what extent is DBBC3 supported in DRUDG? If non/limited; do we know what is lacking?

Currently only handles git repos.

On Jun 12, 2020, at 8:04 AM, @BeppeMc wrote:

Hi Ed,

playing with GNPLT I noticed only now that statistic panel has 2nd term and known term labels swapped.

See attach.

Cheers, Beppe.

This apparently dates back the first version of gnplt(2) in a3483ef (Aug 2009).

Remove for that case?

If the FS is in /usr2/fs-git, the wrong link is set for /usr2/fs. Maybe the solution is to use the last directory field from pwd BEFORE the script cd's to /usr2. Maybe:

DIRECTORY := ($shell echo $(pwd) | rev| cut -d/ -f1|rev)

And then use $DIRECTORY everywhere in place fs-$FS_VERSION

This should handle git repos (whether name fs-git or not) or archive versions that would the version explicit in the directory name, e.g. fs-10.0.0.

Maybe POSIX IPC has something. If so maybe the libraries could rewritten using that. Maybe we should get off system V anyway. Maybe POSIX would give us longer message queues (or is having these smallish better anyway).