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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox