Hi Steve! Am 21.03.2011 18:58, schrieb Steve Langasek: > On Mon, Mar 21, 2011 at 11:30:06AM +0100, Michael Biebl wrote: > > Right, in the policy proposal I am describing that each init script is > responsible for checking this. But the actual *implementation* of this > check can and should use a common shell library to do the heavy lifting. > Sorry, I didn't think that specifying that belonged in policy. Do you think > the use of a common shell library should be enforced in policy as part of > this? I do think it would make sense to agree on the name of such a shell library and at least mention and recommend it in the policy text. My concern is that if we don't encourage a common shell lib we get all sorts of inconsistencies and if we need to make adjustments later on (return codes etc) it's much easier to do it in one place. >> I'd much prefer if we could use the /lib/lsb/init-functions lib to do the >> same kind of redirecting for upstart. That is, all a package needs to do >> if it ships a native upstart job (or systemd service), is to include . >> /lib/lsb/init-functions in its sysv init script. lib/lsb/init-functions >> /would then do the correct thing, when it is run under >> systemd or upstart. > >> Steve, do you think this would be an approach that works for upstart (and >> Ubuntu)? > > I hadn't thought about having /lib/lsb/init-functions automatically do this > checking when sourced. I think on some level the idea offends me, the same > way having C libraries call setuid() or exit() offends me. :) Also, this > check is only needed for those packages that *ship* an upstart job, and > surely those packages know who they are and can handle the conversion easily > enough if we give them a function to call? True. The current version of upstart does not (yet) natively support SysV init scripts, and relies on /etc/init.d/rc to start those services. SysV services in upstart don't run under the supervision of upstart. In systemd the situation is a bit different, as SysV init scripts are basically just another configuration source and we also want to start SysV services under the supervision of systemd. I remember though Scott saying though that "native" SysV support was planned in upstart. So I'm just thinking ahead a bit. Using /lib/lsb/init-functions has the huge advantage that we already have a pretty good coverage of SysV init scripts using it (~70 %), which don't need to be changed to support this redirection scheme. For upstart with its current features, the shell lib would only redirect the call to initctl/upstart if if finds a upstart job with the same name as the SysV init script and would be a nop otherwise. Regarding the redirection scheme and your loathing of exit, how would you envision such an interface should look like? Cheers, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?
Description: OpenPGP digital signature