On 09/21/10 15:07, [email protected] wrote:
On 09/21/10 14:12, [email protected] wrote:
Hi,
I also had a similar question, with the following scenario in mind.
Starting a daemon from rc.sysinit also becomes a problem if there is a
need to add new a daemon that has to be started *before* a daemon
started
by rc.sysinit.
It will require developers to modify fastinit package and add a
dependency
to the fastinit package into their own.
What is the reason that these daemons are started by rc.sysinit instead
of
individual init scripts ? This also is an interesting choice considering
that rc.sysinit is not the traditional place to start system daemons.
1) elimination of endless shell scripts:
init calls /etc/rc.d/rc calls /bin/bash calls /lib/lsb/init-functions
calls /sbin/service calls /etc/init.d/$servicename calls
a-bunch-of-nonsense-checks calls way-too-much-bash-code calls... etc.
All of these are a waste of time.
2) there are only 2 daemons with hard dependencies started (udevd/dbus
--system), not 15-20 you normally see on a desktop.
3) it scales. We're not talking about a server withy 60-70 services
running. It's a mobile device with very limited services (and we want to
keep it that way)
4) putting road blocks in place for new services prevents people from
adding unneeded services. And unfortunately, this is really needed. You
don't want to know how often we have removed cupsd from starting up by
default :/
If someone really needs to add a system daemon for a good reason,
there's no need to bypass the people who own this part of MeeGo and work
with us.
Since these daemons would most likely be specific to a device (thats my
case anyways) this could become a maintenance problem for the fastinit
package owner.
Also, since creating init script for starting daemons still is an option,
this doesnt really stop developers from creating and adding new system
daemons. It is an issue only if the new daemon has dependency on one
started from rc.sysinit. So
yes, there's a small amount of "creep" where init.d scripts crawl back
in. There's no big problem with that, I do a sweep of them once in a
while and we try to get rid of the ones that are misplaced or not
needed. Some will eventually remain here, and that's fine.
Do you have a concrete issue where something "becomes a problem if there
is a need to add new a daemon that has to be started *before* a daemon
started by rc.sysinit." ?
We have a system daemon that mediates communication between the
applications (MeeGo) processor and the modem. This daemon needs to come up
before anything that talks to modem - oFono is one example.
That immediately raises questions:
- is your daemon well-written, such that, once it forks into the
background, it's actually up and running and ofono can be immediately
started?
The following scriptlet (for instance) does NOT work:
# dbus-daemon --system --fork ; hald --daemon=yes
and is a pain to solve once you figure out that you're just starting too
fast :) (btw, normal distributions will likely never see this issue
since they have several scripts executing in between these 2 thus
masking the issue).
- also, what's the exact nature of the problem that your daemon needs to
be started before ofonod? Could you implement this in a pluggable way
such that this dependency is not needed? That would for instance make
your daemon restartable (I assume it's not right now) and much more robust.
_______________________________________________
MeeGo-dev mailing list
[email protected]
http://lists.meego.com/listinfo/meego-dev
