Re: gpilotd sync problems - workaround?

[Dagmar d'Surreal <dagmar speakeasy net>]

On Fri, 2003-07-11 at 04:29, Szabó Balázs (dLux) wrote:
> I don't have it fully working either, but I did a dirty trick in my
> gpilotd source:
> 
> In the visor_devices_in function, I added a while cycle, which waits
> until the Treo really exists in the /proc/bus/usb/devices. It sleeps
> until it can found it. Of course it can be run only from a terminal.
> 
> It seems that /proc/bus/usb/devices is not refreshed at the time when
> you push the HotSync button, only after 4-5 seconds (I use kernel
> 2.5.70), and this causes the problem. If I use the following
> coreography, it works:
> 
> - kill any accidentally-running gpilotd
> - start the hacked ./gpilotd from a terminal
> - push sync button
> - kill the gpilotd (Ctrl+C)
> 
> This gpilotd process can be used only for one synchronization, it
> won't wake up again if you push the button again.
> 
> Sometimes I got "Unable to bind to pilot" message at the first try,
> but It always work for second time.
> 
> Did it help?

Okay, I've been mulling this over for a bit, and while I can do signal
handling in perl, gpilotd isn't written in perl.   ;)  If you're already
doing brutish things to your source, see if you can tie an unused signal
(SIGUSR2 maybe) to the same thing that happens when you right click the
gnome-pilot applet and select Restart, because so far, I've had zero
problems hitting the sync button and then restarting gpilotd through the
applet control like that.  With that signal handler in place, the
hotplug subsystem can be readily pressganged into firing off a SIGUSR2
at anything named gpilotd, which _should_ solve the problem.  (I tried
to just send it a hangup already and that didn't work for reasons I
don't quite grok).