[RFC] Cleaning up service handling in OE

[RFC] Cleaning up service handling in OE

[Paul Sokolovsky]

Hello openembedded-devel,

  By service, I mean /etc/init.d/* scripts, which all follow
start/stop command convention, etc. They also can autostart on boot or
not. This is actually the topic of this RFC - to call for discussion
of guidelines the packages should follow in their wish to install
their services for autostart on boot.

  A specific case which makes me raise this question is irda-utils
packages which includes irattach service, which it bothers to install
for autostart. The result of this is that IrDA is being activated
unconditionally on boot, eating power, and disallowing other processes
to control IrDA port on their own. The only reason it doesn't hit many
users is that service script itself broken and fails to detect IrDA
port on most of machines.

  I checked that 2 major GUI frameworks, GPE and OPIE, use own means
to control IrDA nd do not depend on irattach service. So, I'd like to
proceed with following:

1. Fix port detection for irattach service so it would apply to most
PXA devices to start with.
2. But leave it out of autostart, leaving this matter to user.


  I hope that for this case, proposed steps are unambiguous, but
again, I'd like to extend scope of this RFC to discuss generic
guidelines for all services. Another possible usecase: user install
mysql server. This is reasonably heavy package for embedded system.
So, should package make it autostart or no?

  I'd guess, this largely depends on the answer to question "How hard
for end user to control service's autostart setting?". OE uses update-rc.d
script for this, and arguably, it's not very userfriendly - while
removal from autostart takes just remove command and service name, for
adding to autostart, user needs to specify priorities explicitly, and
that's easy to get that wrong.

  I'm not sure how Debian solves this issue, but RedHat systems has
chkconfig utils, which, while having confusing name, has nice feature
of using defaults provided in service script itself, for example:

-- avahi-daemon --
#! /bin/sh
#
# avahi-daemon:       Starts the Avahi Daemon
#
# chkconfig: 345 98 02
[]
------------------

  Would it be reasonable to add such feature to update-rc.d script?


-- 
Best regards,
 Paul                          mailto:pmiscml@gmail.com

Re: [RFC] Cleaning up service handling in OE

[Paul Sokolovsky]

Hello,

Thursday, April 5, 2007, 5:39:20 PM, you wrote:

> Hello openembedded-devel,

>   By service, I mean /etc/init.d/* scripts, which all follow
> start/stop command convention, etc. They also can autostart on boot or
> not. This is actually the topic of this RFC - to call for discussion
> of guidelines the packages should follow in their wish to install
> their services for autostart on boot.

>   A specific case which makes me raise this question is irda-utils
> packages which includes irattach service, which it bothers to install
> for autostart. The result of this is that IrDA is being activated
> unconditionally on boot, eating power, and disallowing other processes
> to control IrDA port on their own. The only reason it doesn't hit many
> users is that service script itself broken and fails to detect IrDA
> port on most of machines.

  Ok, this was fixed.

  Comments for general improvements to service handling are still
welcome!

[]



-- 
Best regards,
 Paul                            mailto:pmiscml@gmail.com

Re: [RFC] Cleaning up service handling in OE

[Tom Walsh]

Paul Sokolovsky wrote:
> Hello openembedded-devel,
>
>   By service, I mean /etc/init.d/* scripts, which all follow
> start/stop command convention, etc. They also can autostart on boot or
> not. This is actually the topic of this RFC - to call for discussion
> of guidelines the packages should follow in their wish to install
> their services for autostart on boot.
>
>   A specific case which makes me raise this question is irda-utils
> packages which includes irattach service, which it bothers to install
> for autostart. The result of this is that IrDA is being activated
> unconditionally on boot, eating power, and disallowing other processes
> to control IrDA port on their own. The only reason it doesn't hit many
> users is that service script itself broken and fails to detect IrDA
> port on most of machines.
>
>   I checked that 2 major GUI frameworks, GPE and OPIE, use own means
> to control IrDA nd do not depend on irattach service. So, I'd like to
> proceed with following:
>
> 1. Fix port detection for irattach service so it would apply to most
> PXA devices to start with.
> 2. But leave it out of autostart, leaving this matter to user.
>
>
>   I hope that for this case, proposed steps are unambiguous, but
> again, I'd like to extend scope of this RFC to discuss generic
> guidelines for all services. Another possible usecase: user install
> mysql server. This is reasonably heavy package for embedded system.
> So, should package make it autostart or no?
>
>   I'd guess, this largely depends on the answer to question "How hard
> for end user to control service's autostart setting?". OE uses update-rc.d
> script for this, and arguably, it's not very userfriendly - while
> removal from autostart takes just remove command and service name, for
> adding to autostart, user needs to specify priorities explicitly, and
> that's easy to get that wrong.
>
>   I'm not sure how Debian solves this issue, but RedHat systems has
> chkconfig utils, which, while having confusing name, has nice feature
> of using defaults provided in service script itself, for example:
>
> -- avahi-daemon --
> #! /bin/sh
> #
> # avahi-daemon:       Starts the Avahi Daemon
> #
> # chkconfig: 345 98 02
> []
> ------------------
>
>   Would it be reasonable to add such feature to update-rc.d script?
>
>   
As a heavy Mandriva user, I prefer the chkconfig way of doing things.  
For three reasons:

1. It is a "standard" method of managing init scripts already in use.

2. You can change the order of services quickly without deleting / 
adding symlinks manually.

3. My eyes glazed over when I read the update-rc.d script.

Regards,

TomW




-- 
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net http://cyberiansoftware.com http://openzipit.org
"Windows? No thanks, I have work to do..."
----------------------------------------------------

Re: [RFC] Cleaning up service handling in OE

[Michael 'Mickey' Lauer]

Thanks for raising this issue, Paul.

The state of the service handling in OE has buggered me since long,
not just because of the (very valid) points you mentioned, but also
because of their relationship to sysvinit -- the initscripts are just
too specialized in my opinion.

One example: I can see OpenMoko moving to another sysinit scheme,
most likely upstart. Now how are we (OE) supposed to support that
while keeping sysinit support updated at the same time.

We should do it like we support different packaging systems and image
types -- let me propose going to a more high level description for service
handling and having a bbclass (INHERIT += sysvinit or INHERIT +=
upstart) parsing this description and emitting
the actual init scripts.

What do you think?

Regards,

:M:
-- 
Michael 'Mickey' Lauer | IT-Freelancer | http://www.vanille-media.de

Re: [RFC] Cleaning up service handling in OE

[Paul Sokolovsky]

Hello Michael,

Tuesday, April 10, 2007, 2:25:39 PM, you wrote:

> Thanks for raising this issue, Paul.

> The state of the service handling in OE has buggered me since long,
> not just because of the (very valid) points you mentioned, but also
> because of their relationship to sysvinit -- the initscripts are just
> too specialized in my opinion.

> One example: I can see OpenMoko moving to another sysinit scheme,
> most likely upstart. Now how are we (OE) supposed to support that
> while keeping sysinit support updated at the same time.

> We should do it like we support different packaging systems and image
> types -- let me propose going to a more high level description for service
> handling and having a bbclass (INHERIT += sysvinit or INHERIT +=
> upstart) parsing this description and emitting
> the actual init scripts.

        Sorry, I'm not much familiar with alternative startup
managers, so it took me some time to glance over upstart as an
example. So, instead of symlinks to predefined set of dirs, it uses
small file descriptor for each service script, which specifies
parameters, dependencies, etc.

        Then yes, I see what you propose as a good idea. For this, we
would rename update-rc.d.bbclass to sysvinit.bbclass for example (as
its purpose is exactly handling sysvinit's view of things).

        As for specific implementation, I guess this still should
start with adding initial upstart support per se. My guess is that
it's quite probable that we can abstract typical service parameters,
and make specific bbclass implement them in term of some startup
system, but only practice can tell ;-). In worst case, separate
descriptors would need to be written, but at least with
INHERIT += <startup_man>, one needed can be selected by bbclass,
without further specification in .bb.

> What do you think?

> Regards,

> :M:



-- 
Best regards,
 Paul                            mailto:pmiscml@gmail.com