Michael Biebl <[email protected]> writes: > On Mon, 09 Nov 2020 00:40:31 +0100 =?utf-8?q?Ferenc_W=C3=A1gner?= > <[email protected]> wrote: > >> I was surprised that a daemon start failure during install did not stop >> dpkg from exiting with a successful exit status. After much digging I >> found https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=766194#22, which >> explains the asymmetry with dh_installinit. > > I'm not sure there is an asymmetry with sysvinit, on the contrary.
Hi Michael, I actually took the wording from the linked comment, where Niels wrote: "Note that debhelper's tooling for init scripts vs. systemd has the asymmetry that the systemd tooling ignores all failures basically." Since the maintainer script snippets generated for SysV init scripts don't ignore the init script failures, the asymmetry is clearly present. But let's not dwell on this. >> While I'd find an option for this more appropriate than different >> behavior, I also feel like the current state merits some much more >> prominent documentation at least. Please consider addig it to the >> respective compat level as well. > > The "not-fail-on-failures" in dh-systemd (and later dh_installsystemd) > was modelled after sysvinit where SysV init scripts typically have an > "exit 0" at the end of the init script, thus basically ignoring any > error in the init script. Maybe, but that's at the clear discretion of the package maintainer. (And I don't find it correct practice, but that's not my point now.) > systemd/systemctl internally is more strict, that's why we picked the > "|| true" approach to mimic the old sysvinit behaviour. My problem is that this rather mimics badly written init scripts, without even warning the maintainers (who supposedly want to take advantage of the more correct/strict systemd behaviour) or letting them opt out (without wholly ditching the debhelper maintscript snippets). > Obviously, we could change that to be more picky and abort if a service > fails to start. Question is: do we want that? And if so, why? See above. But I'm not sure that changing behaviour would be a good idea, that's why I asked for documentation in this report. I was bitten by this in autopkgtest settings, so I'll be adding daemon status checks to my autopakgtests. It just took me too long to find out that this behaviour is intended, because I didn't expect the above asymmetry and the manual pages don't mention it either. -- Thanks, Feri
