Most of the services in the emon family are already systemd so getting rid of the dependency on rc.local is indeed the largest share of the work, believe it or not, it would be quite easy to achieve code wise, the tricky part could be getting the changes adopted, for some reason there has been significant resistance to moving away from using rc.local.
Much of the content of rc.local can be removed just by sorting the logging to ram properly. I have put forward using log2ram, with some subtle changes. I have been using it for some time and it solves all the issues derived from having the log files in RAM, in fact it improves thing significantly as not only does it fix the logfile creation, it also persists logfiles accross reboots and manages the size in RAM better. But using this specific solution or another is for another discussion, the point here is the large part of the rc.local content can be grouped and resolved as one thing, leaving very little else to tackle.
Below is the current rc.local file chopped into 4 sections
Section 1,
the header, just a shebang and prints the ip address. non-essential and easy to drop.
#!/bin/sh
#
# rc.local
echo" My IP address is":
hostname -I
Section 2,
I’m not sure where this originates from, but it was introduced in this commit restart interface is require, belt and braces wifi check script · openenergymonitor/emonpi@90b2ef1 · GitHub it looks like some sort of forced reset by deleting the /var/run copy of wlan0 config? Surely that file is brand new at reboot?
# WLAN fix on RasPi 3B+ Stretch
rm /var/run/wpa_supplicant/wlan0
ifdown wlan0
sleep 1
ifup wlan0
Section 3,
This is the larger portion that can be dealt with in one blow, it all revolves around recreating the log files and folders that were lost when rebooting and changing thier ownership and permissions etc.
# Will only run if /var/log is mounted in tmpfs
if ( mount | grep "on /var/log "| grep -q "^tmpfs " )
then
for i in "redis" "apache2" "mysql" "openhab" "logrotate" "mosquitto" "supervisor"; do mkdir /var/log/"$i"; done
for i in "emoncms.log" "mysql.log" "mqtt_input.log" "redis/redis-server.log" "service-runner.log" "mysql/error.log" "apache2/error.log" "supervisor/supervisord.log" "ntp_update.log"; do touch /var/log/"$i"; done
for i in "emoncms.log" "mysql.log" "mqtt_input.log" "redis/redis-server.log" "service-runner.log" "mysql/error.log" "apache2/error.log" "supervisor/supervisord.log" "ntp_update.log"; do ""chmod 666"" /var/log/"$i"; done
chown -R root:adm /var/log/apache2
chown -R redis:redis /var/log/redis
chown -R mysql:adm /var/log/mysql
chown -R openhab:openhab /var/log/openhab
chown -R pi:pi /var/log/logrotate
chown -R mosquitto:mosquitto /var/log/mosquitto
chown -R dataplicity:dataplicity /var/log/supervisor;
# Restart random seed process now ~/data RW partition has been mounted
sudo systemctl restart systemd-random-seed.service
# Start / Restart services,they should run happy now log dir's are created
sleep 3
service mysql restart
service redis-server restart
service mosquitto restart
service emonhub restart
service emonPiLCD restart
service apache2 restart
service supervisor restart
service feedwriter restart
service mqtt_input restart
service lwrfd restart
service service-runner restart
service emoncms_mqtt restart
fi
Section 4,
This should be set up as a service that runs on first boot only by simply enabling a service to run a command && then disable itself. Much like the method Raspbian already uses to expand it’s root partition.
# Run emonPi Update of first factory boot as Pi user (run condition > web connection exisits && ~/data/emonpiu$
su pi -c '/home/pi/emonpi/./firstbootupdate'
(note - It looks like the su pi is not exited so the next part is being run as user pi too!)
Section 5,
This looks like it too could/should be a service that is simply enabled/disabled like any other service.
## Start Wifi AP (uncomment if required) see emonpi/wifiAP/readme.md
/home/pi/emonpi/wifiAP/startAP.sh
and that leaves just the exit line
exit 0
So if (for example) we implemented log2ram that would be section 3 taken care of, aside from sections 4 and 5 just needing fairly straight forward new services added to replace them (perhaps amending the user and paths to something more universal along the way?) only section 3 needs tackling, possibly by resolving the need rather than re-implementing the workaround in systemd (if it is a workaround that is).
If needed I can go into the history and current requirements of the tmp logfiles in more depth, what’s been tried and suggested etc, this has been discussed in great depth many, many times over the last few years, it’s all on the forum if you do want to read up on it, quite a bit of time has been sunk into different solutions but none adopted or even tested to any real degree, so be wary of investing too much time on this, you could be reinventing the wheel and/or not make it to press.
.
]
