vhusbdpin takes 30 seconds to stop in Raspberry Pi

7 posts / 0 new
Last post
roman.saveljev
vhusbdpin takes 30 seconds to stop in Raspberry Pi

Hello,

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:

pi@raspberrypi ~ $ sudo service vhusbdpin start
pi@raspberrypi ~ $ time sudo service vhusbdpin stop

real 0m30.111s
user 0m0.730s
sys 0m2.100s

I was able to collect the following log: http://pastebin.com/PRCWCWRh

Is there any way the server could shutdown faster? Please let me know, if there is more info I could provide.

Thanks in advance,
Roman

Michael
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/vhusbdpin and put it in /etc/init.d and reboot your pi and it should be fine now.

roman.saveljev
Thanks Michael for a rocket

Thanks Michael for a rocket-fast support!

Now I am seeing the service gets torn down within ~2 seconds, which is totally acceptable:

pi@raspberrypi ~ $ time sudo service vhusbdpin stop

real 0m2.062s
user 0m0.110s
sys 0m0.190s
pi@raspberrypi ~ $

Cheers!
Roman

roman.saveljev
Hello,

Hello,

I have just picked up the server version 2.3.5 and the service stopping issue started to manifest itself again:

pi@raspberrypi ~/vhusbd $ time sudo service vhusbdpin stop

real 0m30.147s
user 0m0.520s
sys 0m2.350s

This is what I find in the log:

Tue Jul 7 09:58:57 2015 LOG_INFO >>> Starting v2.3.5 (Built: Jul 7 2015, 09:25:53)<<<
Tue Jul 7 09:58:57 2015 LOG_INFO Using configuration /etc/virtualhere/config.ini
Tue Jul 7 09:58:57 2015 LOG_ERR Parsing config encountered error 22, (Invalid argument)
Tue Jul 7 09:58:57 2015 LOG_INFO Server licensed to=00000000f9ccb997 max_devices=unlimited
Tue Jul 7 09:58:57 2015 LOG_INFO Using large URB's
Tue Jul 7 09:58:57 2015 LOG_DEBUG TCPServer starting...
Tue Jul 7 09:58:57 2015 LOG_INFO Listening on all network interfaces at port 7575
Tue Jul 7 09:58:57 2015 LOG_DEBUG TCPServer (7575) started
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
Tue Jul 7 09:58:57 2015 LOG_INFO Found Full speed device [0403:6001] "403, TTL232R-3V3" at address 114
Tue Jul 7 09:58:58 2015 LOG_DEBUG 10.0.1.18 connected
Tue Jul 7 09:58:58 2015 LOG_INFO Device 112 BOUND to connection 1
Tue Jul 7 09:58:58 2015 LOG_INFO Device 114 BOUND to connection 1
Tue Jul 7 09:59:37 2015 LOG_DEBUG Removing connection 1 (server shutdown)...
Tue Jul 7 09:59:37 2015 LOG_INFO Device 112 UNBOUND from connection 1
Tue Jul 7 09:59:37 2015 LOG_INFO Device 114 UNBOUND from connection 1
Tue Jul 7 09:59:37 2015 LOG_INFO Device 112 BOUND to connection 1

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

Any help is greatly appreciated!

Regards,
Roman

roman.saveljev
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

roman.saveljev
I think I get it now.. The

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.

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.

Roman

Michael
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...

Log in or register to post comments