arne anka wrote:
> within normal operation (runlevel) phonefsod does not work predicatble.
> small changes in the phonefsod.conf made it stop entirely (w/o any useful  
> info in the log despite DEBUG) and small changes in eg fsodeviced seemed  
> to fix that ...
> what looks far more confusing to me is, that phonefsod always gets a lower  
> pid than fsodeviced, fsousage or frameworkd -- despite being started later  
> according to the number assigned in /etc/rc3.d:
> S01dbus
> ...
> S02fso-deviced
> S02fso-frameworkd
> ...
> S03phonefsod

I don't know if it applies here, but unusual PIDs can happen as
some daemons fork in order to run in the background, while
others don't fork. Instead, they rely on "start-stop-daemon" or the
startup script to put the process in the background.

The FR is kind of slow, so apps that fork might take some time getting 
to the first fork.

> since accessing (activating?) the gsm means, one of the otheres has to be  
> activae already.
Not necessarily that active. init runs the fso-deviced script, which 
launch the daemon and quits. Then init launch the fso-frameworkd script, 
and so on.

Generally, one script quits before the next starts. But that doesn't 
mean the launched daemon is actually ready for a connection. It may 
still be running early initialization code, such as resolving dynamic 
linking or parsing the config file.

The next daemon to start may get through its initialization much faster,
and try to contact an earlier daemon before it is ready.  Which is why
it is so necessary to have good retry logic. For example:

1. try to access resource
2. if "not ready yet" then sleep 1s, then try (1) again.

It may still be necessary to abort/give up on other kinds of errors, but 
"not ready" is best handled by sleeping a little so the others can catch 
up before the next retry. The sleeping is necessary to avoid busy waiting.

Helge Hafting

Openmoko community mailing list

Reply via email to