Suggestions for features and software you would like to see in DietPi, goes here.
- Posts: 18
- Joined: Tue Jan 15, 2019 5:25 pm
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:
Code: Select all
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
1 timers listed.
- Site Admin
- Posts: 2608
- Joined: Sat Nov 18, 2017 6:21 pm
Many thanks for your suggestion.
dietpi-wifi-monitor.service runs as persistent process with a 10s loop to check connection state and in case reconnect.
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?