Hello,
i.m.o. it would make sense to configure a systemd-timer for DietPi-WiFi-Monitor.
This would include this regular task in output of systemctl list-timers; the current output lists this:
root@pc9-fhem:~# systemctl list-timers -all
NEXT LEFT LAST PASSED UNIT ACTIVATES
Mon 2019-06-10 15:57:58 CEST 6h left Sun 2019-06-09 15:57:58 CEST 17h ago systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.se
rvice
1 timers listed.
THX
74cmonty
Many thanks for your suggestion.
Currently:
dietpi-wifi-monitor.service runs as persistent process with a 10s loop to check connection state and in case reconnect.
Your suggestion:
dietpi-wifi-monitor.timer calls a script every 10s to check connection state and in case reconnect?
So basically the internal loop can be removed but is done by the timer instead.
The disadvantage I see:
Every 10s a “whole” new shell needs to be loaded + some minor values estimated. So from performance/CPU load point of view having the loop inside a single shell session is preferable, IMO.
Generally I think 10s is simply a too short duration for a systemd timer to make sense. If you want to run something every hour or more, it makes sense to not have the process + shell loaded all the time during the actions, but in case of 10s the overhead of loading/unloading shell+env is heavier then the saved RAM usage between the calls due to stopped process, or what you think?