On Thu, Feb 23, 2012 at 08:08:18PM +0000, Tzafrir Cohen wrote: > On Thu, Feb 23, 2012 at 07:24:20AM +0100, Tollef Fog Heen wrote: > > ]] Tzafrir Cohen
> > > In sysv init scripts the daemon forks into the background. In upstrart > > > and systemd it doesn't have to (or shouldn't). (not) forking requires a > > > different command-line argument, normally. This leads to odd beasts such > > > as safe_mysqld. > > You can just use the --background switch to start-stop-daemon with > > sysvinit scripts. > It's still a different command. And anyway, very often the daemon itself > needs to handle the PID files, which means that I can't use that. > But more importantly, start-stop-daemon only starts and stops the daemon > once. It's not a daemon monitor. Would there be any objection if I > replaced init.d scripts in some of my packages with runit configs (as > does the git daemon)? The git daemon offers alternatives: one package with a sysvinit config, and one with a runit config. If that's what you have in mind, I don't think anyone would object. But making your server package use runit exclusively would certainly bring objections. If we actually believed runit was a viable replacement for sysvinit, we could have done *that* transition well before either upstart or systemd even existed; but we didn't, and I think imposing runit on users of your package while Policy 9.3.2 says you should be using sysvinit would be frowned upon. I for one would welcome a policy discussion (i.e., on debian-policy) of how runit fits into the larger question of preserving coherence of the Debian system while allowing maintainers to take advantage of (or experiment with) new innovations. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: Digital signature
