During the development of the service-runner python script, there was some discussion (@Greebo, @pb66, @Paul, @TrystanLea, @glyn.hudson) around Redis not starting cleanly (we have seen that elsewhere as well) and how to manipulate systemd to make startup cleaner. We actually did not find a solution and @Greebo ‘fixed’ it in the python script.
As a result of some other work I have discovered a few things about systemd that may help.
There are a number of different parts to systemd. The most common is .service unit file and that is the one most focus on.
The 2 types of unit file that may help are .timer and .path. If you have the same unit name but different suffixes, systemd associates them together.
In simple terms (to delay start of a unit),
- Create an
any-unit.timerfile (in the same location as theany-unit.servicefile) - Create a
[timer]section that has a directive to delay by x seconds and move the[install]section out of the.servicefile and into the timer file. - Having disabled the original service, use
systemctl enable any-unit.timer. - Depending on the timer used (could be x seconds from boot), the starting of the service will now be delayed by that amount of time.
This can also be done with the .path unit type.
It is know that Redis has been known to crash at startup as the log files have not been created. This might be fixed by ‘dropping in’ a modified .service file, a new .path file (that waits until the log file path exists) and enabling the .path unit file instead. The redis server will then not be started until that path exists.
Unfortunately, this is just theory for me as I don’t run an EmonPi so do not see any Redis Startup issues. Equally, the issue may have gone completely with the movement to a RW filestore so the messing about with log file locations may have gone at the same time.
Still I fixed my issue and learnt some stuff at the same time so a productive evening - just thought I’d pass on the info!