nvi-inc / fs Goto Github PK
View Code? Open in Web Editor NEWVLBI Field System
License: GNU General Public License v3.0
VLBI Field System
License: GNU General Public License v3.0
Remove for that case?
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.
There is no make dependency on the VERSION/RELEASE information. So the information in the executables could be stale. Possible solutions:
Brute force delete the affected .o files on every top level make
Save VERSION/RELEASE information in a file and if different (or missing) apply (1).
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),
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?
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.
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?
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 := (
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.
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.
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.
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?
Only FS items that are needed are lnfch.a and vex.a
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.
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.
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
This is a problem by itself, but more so if fsclient is run as a child of itself as in the default stpgm currently:
fs/st.default/control/stpgm.ctl
Line 6 in 71df302
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.
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. :)
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.
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.
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.
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).
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).
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.
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)
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.
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 -)
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.
Entering "help" or "help=", causes a "help=(null)" to be sent to fsclient and then fsclient crashes.
Two things need to be fixed here:
helpstr_
erroring like thatReported by Jun Yang at Onsala.
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.
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.
Sometimes schedules aren't available on CDDIS, but are on others.
Maybe the support for other data centers could be à la plog.
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:
logit()
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.
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.
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:
include/clib.h
, etc.include/dbbc.h
(maybe these can be merged with the struct definitions that are already there)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
Actually it is /usr2/tle_files
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.
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.
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 ...
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?
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
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
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.
It would be useful to publish the log messages on fsserver too. This will require some code in ddout.
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.
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
Currently only handles git repos.
To what extent is DBBC3 supported in DRUDG? If non/limited; do we know what is lacking?
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.