Unfortunately not. The service unit or init script is managed by by the package manager in the same way the main applications are. Even the proper config files are often switched out by apt-get, example the php.ini. The user is asked if they want to keep the old original or accept the new file. This isn’t the case for the init scripts as the maintainers do not expect them to be changed,
A very good example is actually this very package, Mosquitto. The file you guys are editing at /lib/systemd/system/mosquitto.service doesn’t exist on my totally stock (but not recently updated) emonpi, the service unit is located at /run/systemd/generator.late/mosquitto.service because it was created automatically by systemd-sysv-generator because even at Mosquitto version 1.4.13, it is still shipped with a init.d script located at /etc/init.d/mosquitto.
pi@emonpi(ro):~$ ls -la /etc/systemd/system/mosquitto.service
ls: cannot access /etc/systemd/system/mosquitto.service: No such file or directory
pi@emonpi(ro):~$ ls -la /run/systemd/system/mosquitto.service
ls: cannot access /run/systemd/system/mosquitto.service: No such file or directory
pi@emonpi(ro):~$ ls -la /usr/lib/systemd/system/mosquitto.service
ls: cannot access /usr/lib/systemd/system/mosquitto.service: No such file or directory
pi@emonpi(ro):~$ ls -la /run/systemd/generator.late/mosquitto.service
-rw-r--r-- 1 root root 572 Jan 1 1970 /run/systemd/generator.late/mosquitto.service
pi@emonpi(ro):~$ sudo systemctl status mosquitto.service
â mosquitto.service - LSB: mosquitto MQTT v3.1 message broker
Loaded: loaded (/etc/init.d/mosquitto)
Active: active (running) since Thu 2017-11-02 07:17:21 UTC; 1 weeks 0 days ago
Process: 1656 ExecStop=/etc/init.d/mosquitto stop (code=exited, status=0/SUCCESS)
Process: 1664 ExecStart=/etc/init.d/mosquitto start (code=exited, status=0/SUCCESS)
CGroup: /system.slice/mosquitto.service
ââ1670 /usr/sbin/mosquitto -c /etc/mosquitto/mosquitto.conf
Warning: Journal has been rotated since unit was started. Log output is incomplete or unavailable.
pi@emonpi(ro):~$ ls -la /etc/init.d/mosquitto
-rwxr-xr-x 1 root root 3323 Dec 22 2015 /etc/init.d/mosquitto
pi@emonpi(ro):~$
So if I was to update the service unit or the init.d script, or indeed if either of you had done so say a month ago, after updating those changes would be lost and the new unit located at /lib/systemd/system/mosquitto.service would be totally stock.
This is why it is unwise to alter files that are managed by a package manager in case they get changed. To which I’m sure you’ll say “but that’s unlikely to happen (again/often?)” but that translates to “in the event it was to happen again, and cause a problem, it will most likely be really difficult to locate as no one expects that file to get changed”
If the OS was not adapted to RO, the logfiles would persist a reboot and be there when the service units are called, therefore the closest thing we can get to normal operation is to ensure the logfiles are there ahead of when the service units are called. It is the easiest and the most reliable method, second only to getting the source changed to ensure the files are created in-house by the service unit when absent at boot time.
I’m not sure why this isn’t desirable. The old method has been strongly defended for a long time and this is exactly the same thing as was done previously in the wrong place at the wrong time, I’m just suggesting moving it to the right place, to be done at the right time.
This is the rc.local file on my emonpi
#!/bin/sh
#
# rc.local
/usr/bin/printf " My IP address is\033[0;31m `/sbin/ifconfig | grep "inet addr" | grep -v "127.0.0.1" | awk $
# 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 services,they should run happy now log dir's are created
service apache2 restart
service redis-server restart
service mosquitto restart
service supervisor restart
fi
# Run emonPi Update of first factory boot as Pi user (run condition > web connection exisits && ~/data/emonp$
su pi -c '/home/pi/emonpi/./firstbootupdate'
# wait for mosquitto to restart then restart services than depend on MQTT
sleep 5
service emonPiLCD restart
sleep 5
service mqtt_input restart
service lwrfd restart
## Start Wifi AP (uncomment if required) see emonpi/wifiAP/readme.md
# /home/pi/emonpi/wifiAP/wifiAP.sh start
exit 0
Are you really going to edit 7 individual service units and hope none of these get overwritten rather than writing one bespoke service unit? (And is that more sleeps? So is there now over 20 secs of sleeps in the current rc.local?)
There isn’t actually anything that needs to stay in that file, Exerything relates to creating logfiles or the restarting of services once those logfiles have been created except for su pi -c '/home/pi/emonpi/./firstbootupdate' which would be better served using the same mechanism as used when expanding the filesystem. A simple self deleting service is added and activated before powering down so on the next reboot it runs and deletes itself.
If you would prefer to retain the ability to reset the firstbootupdate (currently you can delete the update log) you could just self-deactivate the service rather than delete and to force a new firstbootupdate you just activate it again.