All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Sokolovsky <pmiscml@gmail.com>
To: openembedded-devel@lists.openembedded.org
Subject: [RFC] Cleaning up service handling in OE
Date: Thu, 5 Apr 2007 17:39:20 +0300	[thread overview]
Message-ID: <1168683040.20070405173920@gmail.com> (raw)

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




             reply	other threads:[~2007-04-05 14:39 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-04-05 14:39 Paul Sokolovsky [this message]
2007-04-06 10:45 ` [RFC] Cleaning up service handling in OE Paul Sokolovsky
2007-04-08 22:47 ` Tom Walsh
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=1168683040.20070405173920@gmail.com \
    --to=pmiscml@gmail.com \
    --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.