Disabling the antenna_wifi service doesn't disable the antenna_wifi service

GoPiGo OS, DexterOS and Bloxter
,
1

Greetings!

Issue:
I am trying to troubleshoot a crontab issue where cron doesn’t appear to be executing the commands given.

System: Charline running GoPiGo O/S 3.0.3

Problem:
When looking through the syslog, it is polluted with continuing HEY! THE ANTENNA SERVICE IS RUNNING!!!, (etc.), type messages every few seconds[1] - which makes finding anything else in the system log a pain.

I have tried the sudo systemctl disable antenna_wifi and sudo systemctl stop antenna_wifi commands which appear to do nothing.

I execute them and reboot - and the antenna LED comes back on once WiFi is connected.  (No, I didn’t check the syslogs because the stop and disable commands don’t return any feedback at all, and the LED responds as it normally would.)

What am I missing?  Did “they” rename it?  (Enabling it does something that a subsequent disable un-does - yet it appears to be ineffective.)

==================== Footnotes ====================

  1. A better and more desirable behavior would be to post ONE startup success message and then only report errors, or stop messages as necessary.
1 Like
2

Yes.

It’s now called wifi_led.service and sudo systemctl disable wifi_led appears to do what is necessary.

Pro Tip:
sudo systemctl --type=service --state=running is Your Friend!  It provides a (paged) list of the actively running services on the system - and, (Bingo!), wifi_led was among them.

1 Like
3

Ouch - really a shame we aren’t allowed access to the real source for GoPiGo OS.

BTW, the antenna_wifi.sh script that the antenna_wifi.service was running every 10 seconds … really, really bad design because it is instantiating a raw GoPiGo3 class object every 10 seconds interfacing to the red board to set the LED, but this instantiation also

  • resets the GPIO for the SPI interface,
  • reads the entire manufacturer info from the board,
  • reads the gpg3_config.json and serial numbers files from the SDcard.
1 Like
4

. . . if for no other reason than it floods the syslog with useless messages.

It would be great if we could limit this - maybe your idea of setting “restart” to “never” isn’t such a bad idea?  Is there a setting for “if it crashes, restart”?

1 Like
5

Yes, but the wifi check would need to be changed to a while loop with a timer instead of once and done.

That would also stop the useless repeated class init calls and the SPI bus traffic.

Ps. The loop should keep wifi status and only access the red board if a LED color or state changes.

1 Like
6

This is a multi-legged beastie.

The /opt/Sam_Dev/install/wifi_led_status.sh script does two things:

  1. It has it’s own 2 second timer that continuously polls.

    • If we assume that a python program that instantiates a class, destroys any and all class instances when it exits, then this doesn’t instantiate a zillion classes because those things that depend on GoPiGo libraries run, do something, and end.

  2. It also pings, (pokes at?), some kind of program autoloader, (autorun.service), which also spams the syslog.

=====================================

What I did:

  1. I disabled the autorun.service

  2. I renamed the wifi_led_status.sh script to wifi_led_status1.sh.

  3. I created a “wrapper” script, wifi_led_status.sh, that simply takes the output of the original script and sends it to /dev/null

Viz.:

#!/usr/bin/env bash
#
# This is a wrapper script for the original wifi_led_status script
# to supress all the noise in the system log.

# We pass the one parameter sent, (either "start" or "stop")

/opt/Sam_Dev/install/wifi_led_status-1.sh $1 > /dev/null 2&>1

The wrapper script, and killing off the autorun.service, effectively suppresses the noise in the syslog without affecting the operation of the LED status script.

This is the original LED status script.
wifi_led_status-1.sh.txt (8.2 KB)

I don’t know if it can be run in such a way that changes to the WiFi status send messages to it or not.  Quite frankly, I don’t know if Bash scripts can handle message queues or not either.

Additional note:
I do not know what the autorun.service and the associated script do that’s important.  I also don’t know if there will be any untoward side-effects.  To the extent that I DID look at the output of the syslog when it was running, it appears to do nothing but cycle.&nbsp" But then again, I could be dead-wrong.

Actually, I know exactly what it does.  Something else puts a file/link/whatever into a special “pending” folder in it’s twig of the filesystem and - if anything’s there - it runs it.  It sets a timer that “bites” every two or three seconds, (I think three), which causes it to re-start itself, check “pending” for anything to do, run them if there is, and die off waiting for the next timer bite.

What I don’t know is why it’s there and what it does that’s important to the robot - it appears to be some kind of auto-installer that works in the background.  Maybe legacy code from Raspbian for Robots or Dexter O/S versions gone by?  Darned if I know. . .

If you have the time, (and who am I kidding?), and want to take a look at that script, go right ahead.  Just don’t blame me. :wink:

I, (like you), am trying to fight other issues and I already spent a day and a half on this beastie.  I want to get back to the display research I want to do.
:man_facepalming:

P.S.
I searched the Dexter Industries GitHub repo, and there’s no mention of that particular script anywhere.

1 Like
7

Did you look at the /etc/systemd/system/autorun.service file?

I remember something using autorun to set the user id, hostname, and perhaps the WiFi SSID/password the runs the very first time PiOS is booted, but I’m not familiar with anyone else using it.

1 Like
8

Absolutely I did.  And you could be absolutely correct in that is the method things are done “on the fly” like that. I can’t find any documentation for it anywhere else, so I’m assuming its a “Dexter” thing.

The service file runs a script located at /opt/autorun/check_for_autorun.sh.

check_for_autorun.sh.txt (331 Bytes)

1 Like