On Thu, Apr 13, 2017 at 10:01:25PM +0100, Jonathan de Boyne Pollard wrote: > ... albeit poorly. If one wants to run daemontools under systemd, svscanboot > is > not the way; svscanboot is a thing of the past > http://jdebp.eu./FGA/inittab-is-history.html#svscanboot , and was a source of > problems long before systemd was invented.
Cool. I wish my Google searching had stumbled upon that, when I was trying to figure out how to do all that stuff. > The world wants you to clean your screen > http://unix.stackexchange.com/a/233855/5132 , and this is merely one of the > ways > that it makes you do so. Some day there will be actual end-user-friendly systemd documentation somewhere, consolidating all of these pieces of wisdom together. I hope. My own contributions toward that effort have been riddled with failure and confusion, for which I am sorry. I'm honestly *trying*, but this stuff is really opaque at times. For instance, just this week I learned three new things: 1) To override parts of a distribution's systemd unit locally, you MUST use the foo.service.d/ method. You can't just put the override bits into an /etc/systemd/system/foo.service file. That would be too easy. 2) The files inside foo.service.d/ MUST end with a .conf suffix. (Cf. the wheezy->jessie apache2 upgrade, and having to rename every single one of my virtual domain config files AND the symlinks to them.) 3) foo.service.d/ must use the CANONICAL service name of whatever it is that you're trying to override. This may not be the same as the Debian package name. For example, the nfs-kernel-server package creates a systemd unit named nfs-server.service with an ALIAS of nfs-kernel-server.service. If you try to create override files in nfs-kernel-server.service.d/ it will not work correctly. They have to be in nfs-server.service.d/ instead. Don't even get me started on sshd.service vs. ssh.service. Do you have any idea how hard it is to notice that extra/missing "d", and figure out why things Simply Do Not Work?
