John Albietz: > I wonder if this will help address a common situation for me where I > install a package and realize that at the end of the installation the > daemon is started using upstart or sysv. > > At that point, to 'supervise' the app, I first have to stop the current > daemon and then start it up using runit or another process manager.
On Debian, for one, they aren't started using upstart or sysv (whatever that is). Maintainer scripts enable them with update-rc.d and start them with invoke-rc.d. You are expected to have update-rc.d and invoke-rc.d tools that are appropriate to your init system, as well as the respective control files of course.
openrc comes with update-rc.d and invoke-rc.d that understand openrc scripts. The sysv-rc package comes with update-rc.d and invoke-rc.d that understand systemd units, upstart jobs, and System 5 rc.d scripts. Ironically, the systemd and upstart packages do not come with their own update-rc.d and invoke-rc.d commands, relying instead upon the sysv-rc package to supply them.
This is all a bit shakey and rickety, though. One well-known fly in the ointment is that what may be a single init.d script for System 5 rc may be multiple service and socket units for systemd, and stopping a socket-activated service for package upgrade might not do the right thing as the socket activation might activate the service unit mid-upgrade.
Last year, I gave Debian Developer Russ Allbery a patch for an improved version of the Debian Policy Manual that sets this out more clearly than the current one. You might want to get it off him. The sections (of the patched document) that you are interested in are 9.3.1.2, 9.3.6, 9.3.6.1, 9.3.6.2, and 9.3.6.3.
