From: Tom Walsh <tom@openhardware.net>
To: openembedded-devel@lists.openembedded.org
Subject: Re: [RFC] Cleaning up service handling in OE
Date: Sun, 08 Apr 2007 18:47:22 -0400 [thread overview]
Message-ID: <461970FA.1090703@openhardware.net> (raw)
In-Reply-To: <1168683040.20070405173920@gmail.com>
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..."
----------------------------------------------------
next prev parent reply other threads:[~2007-04-08 22:47 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-05 14:39 [RFC] Cleaning up service handling in OE Paul Sokolovsky
2007-04-06 10:45 ` Paul Sokolovsky
2007-04-08 22:47 ` Tom Walsh [this message]
2007-04-10 11:25 ` Michael 'Mickey' Lauer
2007-04-23 7:29 ` Paul Sokolovsky
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=461970FA.1090703@openhardware.net \
--to=tom@openhardware.net \
--cc=openembedded-devel@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.