2

I have started playing with HF Packet using a Raspberry Pi running Buster. The AX.25 I have direwolf running a 300 baud modem, use kissattach to create the AX.25 port and then use axlisten and axcall for the packet work.

The problem: I created a beacon every 30 minutes using beacon from ax-tools. I want to cancel that beacon. How do I do it? I do not see an option in the manual for ax-tools. If I set the beacon interval to beacon -t 0 I get an error: beacon: interval must be greater than one minute

How do I cancel a beacon that I set?

Kevin Reid AG6YO
  • 24,195
  • 7
  • 48
  • 101
Joshua
  • 61
  • 4
  • Hello Joshua, and welcome to ham.stackexchange.com! – rclocher3 Feb 22 '22 at 15:31
  • Thank you, Rob. Are you on the QRZ.com forums? I think I recognize your avatar from there. – Joshua Feb 23 '22 at 16:09
  • I have a login there, but I haven't participated in many years. I borrowed the image from Robert Crumb's artwork from the sixties, which was also popular on seventies T-shirts, so maybe you recognize the art from somewhere else. – rclocher3 Feb 23 '22 at 17:46

1 Answers1

1

Use beacon killall. This will kill all your beacons if you have more than one. If you want to keep one of several beacons, you will have to restart them manually. This simply kills all the beacon processes.

In order to kill only one beacon, you have to plan ahead. Each call for a beacon produces a new beacon with a new PID. You don't really know which beacon is which. The solution is to run beacon <port> <text> & when you first call the beacon process. This will give you a PID. This PID is actually one BELOW the PID of the new beacon process. If you record that PID and add one, you can then kill that specific beacon using kill <PID>.

Joshua
  • 61
  • 4
  • Good job answering your own question. Is killing an individual beacon just a matter of killing its process? – rclocher3 Feb 23 '22 at 17:48
  • I did not check to see if each call for a beacon produced a new process or if all beacons are passed to the same process. I suspect the latter. – Joshua Feb 23 '22 at 18:19
  • Either way, you have a fix for the problem. – rclocher3 Feb 23 '22 at 18:24
  • 1
    Did some experimenting. `killall` will remove all beacons. Each beacon gets its own process and corresponding PID. If you want to kill only one beacon, you need to use the specific PID for that beacon. How do you know which beacon is attached to which PID? Really, you don't. If you run `beacon &` this will give you the PID of the process except... the actual PID for the beacon is one higher than what is printed. I'll edit my answer. – Joshua Feb 23 '22 at 19:57
  • 1
    Don't forget `pidof xxx`. I think beacon already forks into the background unless you specify `-f`, so you are trusting that forked PIDs increase monotonically, which is not a guarantee. What you could do is capture the value of `$!` for the purpose of later tearing those processes down. e.g., you have a script or service layer than brings up X beacons and saves the PIDs in `/var/run/beacon_X.pid` or something. Then your tear-down script just does best effort to send the HUP, INT, QUIT, or KILL as necessary based on the contents of those files. –  Feb 23 '22 at 21:04
  • I tried to capture the value of `$!` without success during my testing. `beacon` does fork into the background automatically but running the command with the `&` gives you a PID when you otherwise wouldn't get it. I didn't know about `pidof xxx` but that should be more consistent than taking the PID given and adding one. Worth a shot. I don't have any scripts written to start-up or tear-down my AX.25 stack, I do it by hand at the moment. Thank you for the input. – Joshua Feb 24 '22 at 14:57
  • Bash shell handling is weak, and it is the fault of beacon not to provide a way to control it once forked. At some point this becomes a shell programming or Linux service management question -- much of what is discussed here is already answered on many other SEs. –  Feb 27 '22 at 22:49