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 community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community