[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#591791: [PATCH] Document generic and upstart-specific init-system requirements

On 16.03.2012 23:12, Steve Langasek wrote:
> On Fri, Mar 16, 2012 at 10:57:20PM +0100, Michael Biebl wrote:
>>>> Personally, I would just prefer, if the shell library would forward the
>>>> action requests to the native init system.
>>> But this falls down horribly during the upgrade in a very error-prone
>>> manner.
>> Fwiw, this is a non-issue for systemd, as it treats sysv services and
>> native services alike. So during the upgrade, the old sysv based service
>> is stopped, systemd reloads the service definitions and sees that there
>> is a native one now, and starts the new, native one.
> By what mechanism is the new service started?  I don't see anything here
> distinguishing systemd from upstart.  If the service is being stopped and
> started via invoke-rc.d, you have all the same issues.  If systemd is
> starting the service directly, that's a gross violation of policy.

Under systemd, native and sysv service are all started and tracked by
systemd directly. The sysv based services are created on the fly. They
simplified look like
ExecStart=/etc/init.d/foo start
ExecStop=/etc/init.d/foo stop

The "invoke-rc.d foo stop" call is always forwarded to systemd, which
then calls "/etc/init.d/foo stop", reloads the service definitions
and "invoke-rc.d foo start" will then start the native one.

The big difference is, that the invoke-rc.d calls end up with systemd in
both cases and we let systemd call /etc/init.d/foo stop, instead of
doing it directly.

invoke-rc.d respects policy-rc.d, so I don't see a policy violation.

>> I'm wondering if this couldn't be handled in invoke-rc.d though.
>> If upstart is running, and there is a native upstart job, which is not
>> running though, invoke-rc.d could just call /etc/init.d/foo stop
>> In postinst, when you run invoke-rc.d foo start, it would then start the
>> upstart job.
>> Wouldn't this cover this upgrade case?
> It would; I just don't think invoke-rc.d is the right place for that
> complexity to live.  For instance: if upstart is running, there's an upstart
> job for foo, job foo is not running, and invoke-rc.d calls
> /etc/init.d/foo stop as a fallback: how should invoke-rc.d handle the exit
> code of /etc/init.d/foo?
> All possible answers to that question are sufficiently irksome that I think
> we should avoid putting the complexity in invoke-rc.d.

invoke-rc.d already needs to be upstart aware, so this seems like the
right place to put this logic imho. Putting it in each and every sysv
init script on the other hand looks wrong to me.

Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: