On 01/11/2007, Alain Kalker <[EMAIL PROTECTED]> wrote: > Package: bluez-utils > Version: 3.13-1 > Severity: normal > > > When executing "sudo /etc/init.d/bluetooth restart", pand fails to > register a service with the SDP server. Stopping bluetooth > and then restarting it after a reasonable pause does work. > Enabling debug output and examining /var/log/syslog shows that pand > tries to register the service before hcid has had the chance to > start the SDP server, making this a nice example of a race condition. > > I don't know what the best fix for this would be. In my opinion, hcid > should not daemonize before the SDP server is up. Adding a 'sleep 2' > between stopping and restarting the daemons would be a quick fix, but > reliability of this will depend too much on system load and performance.
(Discaimer: I am putting in just ideas, unfortunately I don't have the time to turn them into actions.) What about adding a status function to the script and wait until the SDP server is up or until a timeout occurs (of course, before testing if the SDP server is up there should be a check to see if the SDP server is enabled, if such a scenario is possible). -- Regards, EddyP ============================================= "Imagination is more important than knowledge" A.Einstein -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
