Native upstart scripts

[Jacek Konieczny]

On Tue, May 04, 2010 at 12:04:39PM +0200, Patryk Zawadzki wrote:
> > I think Upstart support should be implemented as an option, coexisting
> > with current solution, so the administrator may choose what he prefers
> > and even use init.d for some services and upstart for other.
> 
> I was hoping for eventually dropping rc scripts for some services and
> moving them completely to upstart. I see why that might sound scary
> and am ok with having two solutions.

I think we can drop rc-scripts some day, but first the alternative must
be well-tested. Having the two alternatives co-exist every one may gradually 
migrate to upstart in his own pace.

And dropping /etc/rc.d/init.d/* in Th will make another difference to
Ti… I guess we don't wont PLD split even more.

Another thing to consider is LSB compatibility… some services expect
/etc/init.d scripts doing their stuff. 

Maybe we could make /etc/init.d a directory with symlinks to
/etc/rc.d/init.d or the upstart wrapper, depending on what is used to
handle the service?

> I'd opt for having 2 separate -init subpackages, one with the current
> rc.d contents and one with an upstart job description and a simple
> rc.d wrapper that runs "start $foo", "stop $foo" etc.

Extra two subpackages for every daemon? I would prefer to avoid that.

> As for emitting signals, we should add these as required by
> dependencies. I see no gain from adding them to every rc.d script.

Hmm. That makes sense. Some event will be implemented in rc-scripts
(line 'network started').

On the other hand, if we make rc-scripts function which does 
 touch /var/lock/subsys/$name; initctl emit subsys/$name started
and another to:
 rm -f /var/lock/subsys/$name; initctl emit subsys/$name stopped

Then integrating the signals will be very easy.

Greets,
        Jacek