We do not touch system services, just the user installed additional software services, webserver, multimedia daemons and such. We simply "disable" it, which means that systemd does not autostart them on boot and e.g. when upgraded via APT. But this only affects services (names) from a certain list, so your custom service should no be affected. You can find here which services we handle manually: https://github.com/Fourdee/DietPi/blob/ ... rvices#L46
Ended up requiring a timer file to delay it starting.
What you mean by "delay" it starting? Systemd starts it as fast as all units/targets listed in After= and Requires= are up. But After= only affects on services actually handled by systemd, so e.g. if you want something to start after mariadb.service, this will not work on DietPi, that is true. You could use the custom include/exclude list to include you service into dietpi-services handling or exclude one: /DietPi/dietpi/.dietpi-services_include_exclude
, e.g. add + myservice
or - mariadb
Systemd does handling itself as good as it can, since it does not know when the user want to do some maintenance tasks, where running services might cause issues or even end up with corrupted data/database and such. And e.g. if you have Nextcloud running, and so prevent database corruption you stop mariadb, then webserver/PHP access, the cron job and such will throw ugly error messages, spam your log and such. So it is good to have alle related services stopped in a reasonable order. This is something systemd cant do. Also systemd does only know the dependencies, listed in the systemd unit, but e.g. webservers do not depend on PHP, only if you use them in certain ways, having an actual PHP page. PHP does not depend on e.g. a memory cache server, databases and such, but if your PHP pages or a certain PHP module and config setting require them, systemd does not know it. And you cannot add simply all possible services to the systemd unit list where service might or might not rely/depend on, based on the active/inactive modules and how you use it. So systemd does only respect the hard dependencies, while DietPi handles more possible and expected dependencies, based on usual install/usage.