Comment 11 for bug 809646

Revision history for this message
Thomas Goirand (thomas-goirand) wrote : Re: [Bug 809646] Re: Init Script Problems

On 07/13/2011 11:32 PM, gholt wrote:
> Soren, I do think init.d 'stop' should do what swift-init 'stop' does,
> which is the 'stop now, closing any connections' action. The 'shutdown'
> is optional for the init.d scripts, but it is used pretty often during
> upgrades and such.
>
> Thomas, you're right that 'shutdown' isn't a standard parameter of the
> init.d. I'm not sure on the policy for adding another option. As far as
> the difference, 'stop' will exit immediately closing any connections,
> 'shutdown' will stop listening immediately and exit once existing
> connections have been satisfied (long running uploads/downloads etc. can
> take quite some time).

Adding non-standard stuff in an init.d script is fine, as much as I know.

> For swift-init, 'restart' will do the equivalent of a 'stop' and 'start'
> with as little time in between as possible.
>
> For swift-init, 'reload' will do the equivalent of a 'shutdown' and
> 'start' with as little time in between as possible.

We are free to implement what we want for a reload. However, again,
swift-init is a bad idea, IMHO. As much as I understand, it was never
designed to begin with, it was just written by a developer for
convenience. I think that instead of having init.d script calling
swift-init, we should have the opposite way: swift-init should become a
userland tool that calls the init.d scripts when the user asks. What do
you think?

> If you want to get rid of swift-init completely for your packaging here,
> you're certainly welcome to. You can call swift-proxy-server directory
> for instance. SIGHUP is the graceful shutdown, SIGTERM is the stop, that
> sort of thing. I wouldn't recommend that path, but I'm also not the
> packager: those who do the work, get the final say. :)

As wrote Soren, the big issue with swift-init is that it does some
printings on screen, which it shouldn't: lsb-base functions should do
that and decide how, depending on the distribution, device type output,
etc. Think about the fact that maybe, someone one day might want
lsb-base to do its output on a web page (why not?), or maybe even light
up some hardware LEDs, and you get the idea. lsb-base is an abstraction
layer that we really should use, and which is part of so many distributions.

Thomas