virtualgps failures

[setnes]

I had previously uninstalled virtualgps as I use a real USB GPS device to update both the time (via chrony) and my mount (via gpsd INDI driver). This works very well.

Unbeknownst to me, virtualgps came back via an apt upgrade. When it did, it caused problems I could not have anticipated. For example, launching the INDI settings from Cartes du Ciel would take a very long time, and sometimes would simply fail. Also, my ZWO guide camera stopped working altogether. I thought I had a camera issue and spent a lot of time on the field debugging that when I should have, instead, noticed the daemon.log file filling up with virtualgps errors.

I'm not sure what is wrong with virtualgps, but its failures caused other devices to stop working. Once I shut the service off, everything works.

These messages are from /var/log/daemon.log.. they were very persistent.

Feb 23 16:16:56 astroberry systemd[1]: virtualgps.service: Service RestartSec=10s expired, scheduling restart.
Feb 23 16:16:56 astroberry systemd[1]: virtualgps.service: Scheduled restart job, restart counter is at 46.
Feb 23 16:16:56 astroberry systemd[1]: Stopped Virtual GPS.
Feb 23 16:16:56 astroberry systemd[1]: Started Virtual GPS.
Feb 23 16:16:56 astroberry python3[1886]: Traceback (most recent call last):
Feb 23 16:16:56 astroberry python3[1886]:   File "/usr/bin/virtualgps.py", line 54, in <module>
Feb 23 16:16:56 astroberry python3[1886]:     os.symlink(pty,virtualgps_dev)
Feb 23 16:16:56 astroberry python3[1886]: FileExistsError: [Errno 17] File exists: '/dev/pts/2' -> '/tmp/vgps'
Feb 23 16:16:56 astroberry systemd[1]: virtualgps.service: Main process exited, code=exited, status=1/FAILURE
Feb 23 16:16:59 astroberry gpsdctl: gpsd_control(action=add, arg=/tmp/vgps)
Feb 23 16:16:59 astroberry gpsdctl: reached a running gpsd
Feb 23 16:16:59 astroberry gpsdctl: gpsd_control(action=remove, arg=/tmp/vgps)
Feb 23 16:16:59 astroberry gpsdctl: reached a running gpsd
Feb 23 16:16:59 astroberry systemd[1]: virtualgps.service: Failed with result 'exit-code'.
Feb 23 16:17:09 astroberry systemd[1]: virtualgps.service: Service RestartSec=10s expired, scheduling restart.
Feb 23 16:17:09 astroberry systemd[1]: virtualgps.service: Scheduled restart job, restart counter is at 47.
Feb 23 16:17:09 astroberry systemd[1]: Stopped Virtual GPS.
Feb 23 16:17:09 astroberry systemd[1]: Started Virtual GPS.
Feb 23 16:17:09 astroberry python3[1904]: Traceback (most recent call last):
Feb 23 16:17:09 astroberry python3[1904]:   File "/usr/bin/virtualgps.py", line 54, in <module>
Feb 23 16:17:09 astroberry python3[1904]:     os.symlink(pty,virtualgps_dev)
Feb 23 16:17:09 astroberry python3[1904]: FileExistsError: [Errno 17] File exists: '/dev/pts/2' -> '/tmp/vgps'
Feb 23 16:17:09 astroberry systemd[1]: virtualgps.service: Main process exited, code=exited, status=1/FAILURE

Thanks again for everything you have created. Hopefully this issue description helps save someone else from an evening of debugging on the field. :)

[rkaczorek]

Thanks for the report. It has been just fixed and pushed to the repository

[setnes]

That's really awesome you changed it. I don't think it fixed the behavior I described though. When it's running, it is still failing and causing problems. I might not have the latest. I installed via apt upgrade. (there was a new version)

Also, when virtualgps updates via apt upgrade, it re-enabled the service. Is there anyway to prevent virtualgps from being re-enabled when it gets updated? This is secondary to the problem above. I'm just curious if there's a better way.

[rkaczorek]

If the problem persists after this fix, there must be something wrong on your filesystem. Please make sure that the file /tmp/vgps does not exist before running virtualgps. I guess it exists on your system with some extraordinary access rights, so the virtualgps cannot access it and/or remove it.

I will look into re-enable issue so it does not come back after disabling by a user.

[setnes]

The file /tmp/vgps does not exist on my system.

[rkaczorek]

Fixed in virtualgps_1.0.1-1