<p>Hello,
</p>
<p>I have installed init.d service to launch the VirtualHere service on boot up in Raspberry Pi. It works quite well, but the time it takes to stop it is 30 seconds:
</p>
<p>pi@raspberrypi ~ $ sudo service vhusbdpin start<br />
pi@raspberrypi ~ $ time sudo service vhusbdpin stop
</p>
<p>real 0m30.111s<br />
user 0m0.730s<br />
sys 0m2.100s
</p>
<p>I was able to collect the following log: http://pastebin.com/PRCWCWRh
</p>
<p>Is there any way the server could shutdown faster? Please let me know, if there is more info I could provide.
</p>
<p>Thanks in advance,<br />
Roman</p>
Found a bug in the vhusbdpin
Found a bug in the vhusbdpin script. Download it again from http://www.virtualhere.com/sites/default/files/usbserver/scripts/vhusbd… and put it in /etc/init.d and reboot your pi and it should be fine now.
Thanks Michael for a rocket
<p>Thanks Michael for a rocket-fast support!
</p>
<p>Now I am seeing the service gets torn down within ~2 seconds, which is totally acceptable:
</p>
<p>pi@raspberrypi ~ $ time sudo service vhusbdpin stop
</p>
<p>real 0m2.062s<br />
user 0m0.110s<br />
sys 0m0.190s<br />
pi@raspberrypi ~ $
</p>
<p>Cheers!<br />
Roman</p>
Hello,
<p>Hello,
</p>
<p>I have just picked up the server version 2.3.5 and the service stopping issue started to manifest itself again:
</p>
<p>pi@raspberrypi ~/vhusbd $ time sudo service vhusbdpin stop
</p>
<p>real 0m30.147s<br />
user 0m0.520s<br />
sys 0m2.350s
</p>
<p>This is what I find in the log:
</p>
<p>Tue Jul 7 09:58:57 2015 LOG_INFO >>> Starting v2.3.5 (Built: Jul 7 2015, 09:25:53)<<<<br />
Tue Jul 7 09:58:57 2015 LOG_INFO Using configuration /etc/virtualhere/config.ini<br />
Tue Jul 7 09:58:57 2015 LOG_ERR Parsing config encountered error 22, (Invalid argument)<br />
Tue Jul 7 09:58:57 2015 LOG_INFO Server licensed to=00000000f9ccb997 max_devices=unlimited<br />
Tue Jul 7 09:58:57 2015 LOG_INFO Using large URB's<br />
Tue Jul 7 09:58:57 2015 LOG_DEBUG TCPServer starting...<br />
Tue Jul 7 09:58:57 2015 LOG_INFO Listening on all network interfaces at port 7575<br />
Tue Jul 7 09:58:57 2015 LOG_DEBUG TCPServer (7575) started<br />
Tue Jul 7 09:58:57 2015 LOG_INFO Found High speed device [15ba:002b] "15ba, Olimex OpenOCD JTAG ARM-USB-OCD-H" at address 112<br />
Tue Jul 7 09:58:57 2015 LOG_INFO Found Full speed device [0403:6001] "403, TTL232R-3V3" at address 114<br />
Tue Jul 7 09:58:58 2015 LOG_DEBUG 10.0.1.18 connected<br />
Tue Jul 7 09:58:58 2015 LOG_INFO Device 112 BOUND to connection 1<br />
Tue Jul 7 09:58:58 2015 LOG_INFO Device 114 BOUND to connection 1<br />
Tue Jul 7 09:59:37 2015 LOG_DEBUG Removing connection 1 (server shutdown)...<br />
Tue Jul 7 09:59:37 2015 LOG_INFO Device 112 UNBOUND from connection 1<br />
Tue Jul 7 09:59:37 2015 LOG_INFO Device 114 UNBOUND from connection 1<br />
Tue Jul 7 09:59:37 2015 LOG_INFO Device 112 BOUND to connection 1
</p>
<p>Just to make sure this is not any kind of user error I am providing you with vhusbdpin script (I have updated it per your previous comment and did little changes myself): http://pastebin.com/kUF00fwL
</p>
<p>Any help is greatly appreciated!
</p>
<p>Regards,<br />
Roman</p>
Hi,
Hi,
The issue does not happen every time. The reason why I am so interested in shutdown time is that we have to reboot raspberry pi quite often to completely reset connected devices as well. So, the system shutdown time is affected: 47 seconds vs 18 seconds
Thanks,
Roman
I think I get it now.. The
<p>I think I get it now.. The server shutdown takes extended time, when it has an active connection with the client. If I kill client before stopping the service it takes 2-3 seconds to put the server down.
</p>
<p>I can change the script to do 'kill -9' on vhclient. I have also discovered that, when there is an active server connection the ACPI fails to gracefully shutdown the machine with the vhclient. So, it needs to be disposed of anyway.
</p>
<p>Roman</p>
It you are using a device and
It you are using a device and shutting down the server at the same time (i think you are auto-using) it can get into a state where the client and server do not exit gracefully, i actually think this is why you are finding this issue with your docker client as well.
Im not entirely sure why it does this yet, using -9 for the timebeing with the kill and ill take a further look at the shutdown sequence in my code...