I’m just passing through so this will be short[edit - so much for that idea!], I will answer more later. But, why don’t you create a simple init script with a unique name and see what happens when you enable it via systemd?
All the Debian packages for the services in question (mysql, redis etc) are still using init.d and a init script is installed by the package manager. systemd then generates the service units for those services as systemd will only start services via service units.
Did you try it? Offhand I do not know if you can override a “generated” service unit the same way as you can override a native service unit. I would hope you could, but I don’t know, perhaps since it is a init.d script it is limited to the config of that init.d script ie /etc/default/servicename?
Regardless, lets pretend all services (mysql, redis etc) are already native systemd just for a moment. The route you are engaging would mean that every service would require a overriding edited service unit file and any new packages installed by the developers or by the users, will require tweaking, new softwares would possibly fail when first installed, until such time as a edited service unit was in play. This might not be obvious to the average user so it could spell out problems.
And again! even if all sytemd services (and init.d services) were edited so as not to use a log file and put everything to jounalctl. We still have non systemd stuff like emoncms etc that need to be catered for. it will be a messy and incomplete solution.
It will also potentially cause other issues, for example, if all logs are going to journalctl, that’s a lot of traffic, will the “persist in emergency” you suggest still work? I know it will still try to work, but how succesful would it be trying to persiste so much data in a crash situation? It could probably handle just the systemd logs no problem. Plus with all these edits to init.d generated systemd service units, what happens when these services are eventually converted to systemd by the package maintainers, will our edits block the upgrades being pulled in or will our edits get overridden and break things?
For example. (as of a couple onf months ago, haven’t checked recently) the mosquitto packages on Debian were all init.d versions, but the latest version at the mosquitto repos was systemd, they were having issues with it so it wasn’t making mainstream release, but one day it will, where would that leave our mosquito service unit edits? we have no control over when a user will do a apt-get dist-upgrade to tie that in with a patch via the emonpi update routine
To avoid all the individual edits the solution needs to be transparent and work behind the scenes so that all packages and softwares can operate without change, this facilitates easy install and easy maintainance, plus there are no surprised eg when a user googles “where’s my mysql error messages”, “in /var/log” is still a true and relative answer. There’s a lot to be said for trying to stick to existing configurations.
Someone recently said something like
which I agree with entirely, but IMO that would also extend to using stock configurations and setups where ever possible. When you start asking for help and googling stuff, it is very useful if helper and helpee are on the same page. Sometimes it’s hard to recall or overlook things are not stock and certain general advice in blogs and wiki’s etc, will not be aimed at the more exotic configurations.