Continuing "antenna_wifi.service restarts in Buster

GoPiGo
1

Greetings!

While tracking down another issue I took a peek at the syslog.

Note the following messages that are completely filling my syslog making it virtually impossible to find anything else.

Feb 22 20:17:10 Charlie systemd[1]: antenna_wifi.service: Service RestartSec=10s expired, scheduling restart.
Feb 22 20:17:10 Charlie systemd[1]: antenna_wifi.service: Scheduled restart job, restart counter is at 122.
Feb 22 20:17:10 Charlie systemd[1]: Stopped R4R Antenna Wifi Indicator.
Feb 22 20:17:10 Charlie systemd[1]: Started R4R Antenna Wifi Indicator.
Feb 22 20:17:10 Charlie systemd[1]: antenna_wifi.service: Succeeded.
Feb 22 20:17:20 Charlie systemd[1]: antenna_wifi.service: Service RestartSec=10s expired, scheduling restart.
Feb 22 20:17:20 Charlie systemd[1]: antenna_wifi.service: Scheduled restart job, restart counter is at 123.
Feb 22 20:17:20 Charlie systemd[1]: Stopped R4R Antenna Wifi Indicator.
Feb 22 20:17:20 Charlie systemd[1]: Started R4R Antenna Wifi Indicator.
Feb 22 20:17:20 Charlie systemd[1]: antenna_wifi.service: Succeeded.
Feb 22 20:17:30 Charlie systemd[1]: antenna_wifi.service: Service RestartSec=10s expired, scheduling restart.
Feb 22 20:17:30 Charlie systemd[1]: antenna_wifi.service: Scheduled restart job, restart counter is at 124.
Feb 22 20:17:30 Charlie systemd[1]: Stopped R4R Antenna Wifi Indicator.
Feb 22 20:17:30 Charlie systemd[1]: Started R4R Antenna Wifi Indicator.
Feb 22 20:17:30 Charlie systemd[1]: antenna_wifi.service: Succeeded.

These messages go on and on and on and on and on. Every ten seconds. . . . filling my syslog to the point where it is useless for anything else.

Any help would be gratefully appreciated.

2

Only thing is to turn off the led, don’t need it do you?

My util: https://github.com/slowrunner/Carl/blob/master/wifi_led_off.sh

1 Like
3

I’m not sure if I am understanding correctly.
My question was about why it repeats so often and if it’s really necessary to flood the syslog with these messages.

Why is it necessary for that to run constantly?

Can’t it be run as a service that auto-restarts of killed - and only reports exceptional behavior?

P.S.
That link takes me to the Dexter home page.

4

Jimmy, ( who asks “Why is there air?”)

That is the way DI chose to implement the WiFi status indicator. Every 10s it checks the WiFi status and schedules the next execution. The syslog entry is not an output of the indicator code, it is the system reporting changes in system components.

99.9% of GoPiGo3 users do not even know the syslog exists, so does it really matter “why?”

In that post I show how to stop those “offending log entries”, and the link is to a bash script wifi_led_off.sh to do it. I’ll put the code here:

#!/bin/bash

# stop GoPiGo3 antenna_wifi.service
sudo systemctl stop antenna_wifi
# turn off wifi_led
python -c "import gopigo3;GPG=gopigo3.GoPiGo3();GPG.set_led(GPG.LED_WIFI,0,0,0)"
1 Like
5

@cyclicalobsessive is right. Every 10 seconds we verify that the robot is still connected to wifi and keep the antenna on/off accordingly.
For Google Cloud Derby, we removed that, so it can totally be done in Raspbian or Raspbian for Robots (not for DexterOS)

sudo nano /etc/systemd/system/antenna_wifi.service

Remove these two lines:

Restart=always
RestartSec=10

You’ll get a yellow LED once the robot connect to wifi, but it will not be kept up to date. You can even turn it off if you want to save (a tiny amount) of battery power.

1 Like
6

Question: Do log files get trimmed? Or will this eventually fill up the SD card with restart messages in the syslog?

One thought I had, possibly a future update?

Is it reasonably possible to implement a “log-level” type parameter that defaults to “significant events only”? Aside from troubleshooting, I cannot imagine the utility gained by flooding log-files with “heartbeat” messages. Though the auto-restart functionality is useful, the log-file-spam isn’t.

I remember reading the man page for something a while ago that described logging levels like this:
0 - Sparse logging. Critical and severe warnings or errors only. (default)
1 - More verbose logging, all warnings, all errors, and important information messages. (useful for debugging)
2 - Increasingly verbose logging of informational messages, warnings and errors. (You really don’t need this unless you’re one of the package maintainers. Even then you should think twice before using this level.)
3 - Ridiculously verbose logging. Intended for developers with time on their hands.
4 - Unbelievably verbose logging.
5 - Incredibly verbose logging. Useful for creating incredibly large log-files quickly.
6 - Outrageously verbose logging.
7 - Insanely verbose logging - primarily useful for filling up log files and crashing hard drives.

I was chuckling at that for days!

7

The logs are rotated every week (renaming the existing log to filename.number order):

# ls -l /var/log/messages*
-rw------- 1 root root   1973 Jun 10 15:07 /var/log/messages
-rw------- 1 root root  10866 Jun  6 04:02 /var/log/messages.1
-rw------- 1 root root  19931 May 30 04:02 /var/log/messages.2
-rw------- 1 root root 238772 May 23 04:02 /var/log/messages.3
-rw------- 1 root root 171450 May 14 18:29 /var/log/messages.4

the weekly rotated log file is deleted after 4 weeks passed (total logs span a time of 5 weeks). This rotation mechanism is provided by crond and logrotate.

Reference: https://www.thegeekdiary.com/linux-os-service-syslog/

Here is from Carl:

pi@Carl:~/Carl $ ls -l /var/log/messages*
-rw-r----- 1 root adm 53002 Apr 15 06:25 /var/log/messages
-rw-r----- 1 root adm  1064 Apr 12 06:25 /var/log/messages.1
-rw-r----- 1 root adm   193 Apr  6 06:25 /var/log/messages.2.gz
-rw-r----- 1 root adm   182 Mar 29 06:25 /var/log/messages.3.gz
-rw-r----- 1 root adm   191 Mar 23 06:25 /var/log/messages.4.gz

BTW, each logged message is truncated at 1024 bytes [default setting].

1 Like