Has there been a change how CQRLOG uses rigctld.
My rigctld starts on computer startup and I have asked CQRLOG to start rigctld also. It seems that it registers that it can not start rigctld and there is no rigctl. Restart of rigctl do not work.
If I manually kill my running rigctld and restarts CQRLOG wo a running rigctld everything works ok. But then rigctld unloads on exiting CQRLOG.
Rigctld on this station is used by various software therefore I need it running at all times.
73 de Olaf
LA3RK
rigctld and rigctl are two different pieces of software. you make reference to both so I'm just making sure your not confusing the two. rigctld is a daemon and rigctl is basically a front end app
rigctld (the daemon) can be started by CQRLOG but if you already have it running at computer startup I don't think 2 copies would play well together. You should uncheck the box in cqrlog preferences - TRX control - (Run rigctld when program starts) since its already running.
My setup has (RIG model:) set to (2 Hamlib NET rigctl) and not to the radio's brand and model number as I assume that would only be correct if you where only allowing cqrlog to start rigctld and it needed the correct setting for your specific radio.
This is the way it works on my setup. Linux Mint 17.1 box with a Yaesu FT-900 USB/serial cat control!
Hope this helps
73 de KF5RLL
I did notice that cqrlog appears on exit to kill a running rigctld even if it didn't start it! This could be a bug but I will investigate a little more before making any accusations. I'd be interested to see if started by a normal user, cqrlog could kill a rigctld process that was started by root or a daemon user such as wheel as would usually happen at startup
73 de KF5RLL
"... cqrlog appears on exit to kill a running rigctld even if it didn't start it! This could be a bug ..." Although a good option in MUST be configurable. We don't have a serious contesting logger (not speaking about "TR for Linux" which is frozen somewhere and TLF which is rather a toy). After a long investigation, the only option is TR4W which has (unfortunately) its own radio control system. Permanently running rigctld is here a potential conflict!
Many of us run rigctld exclusively with CQRLOG, they need to kill it completely on CQRLOG exit to avoid conflicts with other radio control routines. Anyway, I highly recommend to read (again) the "About" section. CQRLOG is primarily designed as daily logger for CW/SSB DX hunter!
I shut down CQRLOG and on restart, I seem to have lost the rigctld. I have no cluster or radio control. If it killed it, how do I restart it? I have the run rigcld checked to start when I load the program. It was working fine until I closed CQRLOG. I'm running Unbuntu 16.04 and using radio 1 configured for FT2000.
What version are you using? I'm not sure but I think I already fixed this bug long time ago. Please run cqrlog with --debug=1 parameter in a terminal and you should see what is happening.
73 Petr
--
http://HamQTH.com/ok2cqr
https://ok2cqr.com
I'm not sure what your trying to say with "Although a good option in MUST be configurable" or why you reference TR, TLF and TR4W or why your statement: "We don't have a serious contesting logger" has anything to do with rigctld or how cqrlog utilizes it. No disrespect but I'm not exactly sure what point you are trying to make.
Back to the task at hand! After further investigation it appears that cqrlog can and will indeed kill a running rigctld process that not only it didn't start but can even kill one started by root or another user!
How does it do this or better yet why would you allow it to do this. If I start a rigctld as root and switch to my normal login I can not kill the process without at least using "sudo". I understand that if I let cqrlog start rigctld then it should indeed kill it on exit, that would be expected behavior.
Other software like wsjtx or fldigi will happily share a running rigctld so its not unreasonable to think that a user may want to leave it running even if exiting cqrlog.
Just trying to get a handle on whats happening.
I just did a check of rigctld and cqrlog. I prefer to have rigctld running constantly and starting on computer boot.
CQRLOG connects to a running instance of rigctld, but when I then close rigctld, the already running instance is killed. This makes sense if CQRLOG was asked to start rigctld, but not if rigctld was running already.
I have other programs using rigctld outside CQRLOG (wspr, fldigi etc) and when CQRLOG kills rigctld this makes problems for the other programs.
As I see it, CQRLOG should not kill rigctld unless started by CQRLOG.
73 de Olaf - LA3RK
Olaf Devik LA3RK
Hi Olaf,
what version are you using? I just tried it and rigctld was not closed. I have running rigctld in terminal and when I close CQRLOG, it's still running.
73 Petr, OK2CQR
--
http://HamQTH.com/ok2cqr
https://ok2cqr.com
Olaf, What "RIG model" do you have selected under the (Radio one) tab of the (TRX control) tab? I have "2 Hamlib NET rigctl" selected WITHOUT the box checked to "Run rigctld when program starts". The problem persists as you and I described above. Upon further testing, if a "Rig model" other than 2 is selected, CQRLOG doesn't kill a previously started instance of rigctld.
Hey Petr, you or Martin never responded as to why or how CQRLOG can kill a root user started copy on rigctld?
I'm running 2.0.1 for the record
73' KF5RLL
CQRLOG can't kill running rigctld as root. It seems rigctld doesn't like something in communication with cqrlog :(. I tried it several times and it worked, rigctld was still running :(. I have TS-590SG.
73 Petr
--
http://HamQTH.com/ok2cqr
https://ok2cqr.com
I did some testing.
First CQRLOG version is 2.0.1, rig is K3 with standard hamlib driver, CQRLOG connects to rigctld via localhost (rigmodel = 2 in CQRLOG).
Normally rigctld is loaded on boot and CQRLOG is not asked to start rigctld.
Sequence of tests:
1. Reboot PC with K3 on
2. Checks rigctld running - ok
3. Starting CQRLOG - connects ok to running instance of rigctld - ok
4. Closing CQRLOG - rigctld still running - ok
5. Starting CQRLOG - connects ok to running rigctld - ok
6. Starting tlf - connects ok to rigctld - ok - tlf closed - rigctld still ok
7. Starting fldigi - connects to rigctld - ok - closing fldigi - rigctld still ok
8. Closing CQRLOG - now running instance of rigctld disappeared - NOT OK
9. Restarted rigctld in terminal
10. Starting CQRLOG - connects ok to rigctld - ok
11. Closing CQRLOG clicking upper right X - rigctld disappeared - NOT OK
12. Starting rigctld in terminal
13. Starting CQRLOG connects to rigctld - OK
14. Closing CQRLOG via button Quit program - rigctld disappeared - NOT OK
15. Starting rigctld with -vv option
16. Starting CQRLOG connects to rigctld - OK
17. Closing CQRLOG - rigctld disappeared - no error messages in console - NOT OK
18. Starting rigctld with -vv option
19. Starting CQRLOG connects to rigctld - OK
20. Closing CQRLOG via file/close menu choice - rigctld disappeared, no errors shown in console - NOT OK
21. Starting rigctld with -vv
22. Starting CQRLOG in terminal with -d
23. Closing CQRLOG - rigctld still running - OK
24. Restarting rigctld with -vvv
25. Starting CQRLOG with --debug=1, connects ok to rigctld
26. Closes CQRLOG - no errors in CQRLOG terminal - no errors in rigctld terminal - rigctld disappeared
As will be seen, I have yet to find what causes rigctld to shut down on closing CQRLOG and the behaviour is inconsistent with no apparent patterns I can spot. I suspect that there is a problem with the K3 hamlib implementation and maybe not a CQRLOG problem.
I can of course solve this problem by starting CQRLOG via a batch file checking for a running instance of rigctld and restart rigctld if needed before CQRLOG starts.
Regards/73 de Olaf - LA3RK
Olaf Devik LA3RK
I did some of the same testing you performed Oalf.
versions:
hamlib 1.2.15.3 (haven't seen a update in a while but also haven't checked in a while)
cqrlog 2.0.1
This is my rigctld command:
rigctld -m 113 -r /dev/ttyUSB0 -s 4800
(I also tried running higher verbose levels - no significant error or info reported)
A running rigctld on my system will immediately close without a reported error directly after closing cqrlog by any means. also, a root user started rigctld will also close with out error by closing a normal user run instance or cqrlog. This seems to indicate that rigctld is crashing as a normal user process (as I recall) shouldn't be able to close a root process.
I still use cqrlog and everything else seems to work correctly. This is the only problem I have had with the logger. I normally leave it open on my main system in the house and allow the shack computer to connect to the log database.