gpsfake fails to run

Bug #1894330 reported by zebul666
This bug affects 3 people
Affects Status Importance Assigned to Milestone
gpsd (Debian)
Fix Released
gpsd (Ubuntu)
Fix Released

Bug Description

When attempting to run gpsfake, one get the error:

$ gpsfake -c 1 berlin.nmea
Processing berlin.nmea
gpsd:ERROR: can't bind to local socket /tmp/gpsfake-2088.sock
gpsd:ERROR: control socket create failed, netlib error -1
Traceback (most recent call last):
  File "/usr/bin/gpsfake", line 319, in <module>
  File "/usr/lib/python3/dist-packages/gps/", line 730, in run
    raise TestSessionError("daemon died")

It's the same when run as root

Is it an apparmor error or non configured profile ?

ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: gpsd-clients 3.20-8ubuntu0.2
ProcVersionSignature: Ubuntu 5.4.0-45.49-generic 5.4.55
Uname: Linux 5.4.0-45-generic x86_64
ApportVersion: 2.20.11-0ubuntu27.8
Architecture: amd64
CasperMD5CheckResult: skip
Date: Fri Sep 4 20:54:23 2020
InstallationDate: Installed on 2020-08-28 (7 days ago)
InstallationMedia: Ubuntu 20.04.1 LTS "Focal Fossa" - Release amd64 (20200731)
 PATH=(custom, no user)
SourcePackage: gpsd
UpgradeStatus: No upgrade log present (probably fresh install)

Revision history for this message
zebul666 (zebul666) wrote :
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in gpsd (Ubuntu):
status: New → Confirmed
Revision history for this message
Rob Norris (rw-norris) wrote :

I'm using Debian Unstable, but I assume it's the same issue.

Checking the system logs (e.g. via dmesg) reveals entries along the lines of:

audit: type=1400 audit(1606596824.706:63): apparmor="DENIED" operation="mknod" profile="/usr/sbin/gpsd" name="/tmp/gpsfake-5064.sock" pid=5065 comm="gpsd" requested_mask="c" denied_mask="c" fsuid=0 ouid=0

Setting AppArmor for /usr/sbin/gpsd from enforce to complain mode gets gpsfake working again.
(as root):
aa-complain /usr/sbin/gpsd


NB1 To restore enforced mode (as root):
aa-enforce /usr/sbin/gpsd

NB I think the profile used is in /etc/apparmor.d/usr.sbin.gpsd (which is owned by the gpsd package).
But I don't know what should go in there.

Revision history for this message
Paride Legovini (paride) wrote :

Hello and thanks for this bug report. I can confirm the issue affects both Ubuntu and Debian. Given that the bug doesn't interfere with the most common use cases of gpsd, and that gpsd is currently a sync from Debian, I believe this bug would be best fixed in Debian. Ubuntu will then pick up the fix with the next package sync. This will benefit both the distros, minimize the maintenance effort and allow newer versions of gpsd from Debian to land in Ubuntu faster.

I filed:

and I'm linking it to this bug report.

Changed in gpsd (Ubuntu):
status: Confirmed → Triaged
importance: Undecided → Low
Revision history for this message
Bernd Zeimetz (bzed) wrote :

The Apparmor profile was written by Ubuntu people, happy to take a patch for Debian.

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

I fully agree to the case and to Bernds statement :-)

Hi and happy new year everyone btw.

I can recreate the case easily and confirm the confinement issue.
Rules are always only as good as they were used :-)
By extending use cases or by new version changing behavior the rules have to be kept up to date.

And this is one case we forgot but is easy to add.

If anyone can't wait for the update to land you can (always) add local rules to a profile with local overrides (allowing for e.g. custom configs).
In this case the following will get you going without loosing the confinement (which disable/complain mode would).

echo "/tmp/gpsfake-*.sock rw," | sudo tee -a /etc/apparmor.d/local/usr.sbin.gpsd

The rule above got gpsfake going (no more apparmor blocks) in my case.
If you happen to find more by going deeper on that use case let us know.
As long as we have reasonable use cases we can easily add them unless they appear to be very non-secure. And in that case you can still use a custom rule for your config (=still no need to disable the profile)

While adding the rule I found that since Bernd and I added the profile to the package it was also accepted upstream. There were a few follow on fixes that we should integrate as well.
E.g. the gpsfake fix I just wrote is in there already.
We should use that file from upstream and contribute (or patch if needed) to that.

It also seems someone was very frustrated according to the comments in there.
But TBH many many common use cases work fine AFAICS.
I can understand the pain thou if you are not used to it and tried to add some better guidance to the upstream profile.

I've submitted a PR for this at:

And to use the upstream one in the packaging at:

Changed in gpsd (Ubuntu):
status: Triaged → In Progress
Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

FYI - the fix for this is in hirsute-proposed right now as Bernd has accepted my changes and uploaded them to Debian (we are in sync atm).

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package gpsd - 3.22-2

gpsd (3.22-2) unstable; urgency=medium

  [ Bernd Zeimetz ]
  * [66691096] Update Apparmor profile from upstream git HEAD.
    Thanks to Christian Ehrhardt (Closes: #976152) (LP: #1894330)

  [ Christian Ehrhardt ]
  * [63f0cbf0] symbols: nanowait came back as (int, timespec*)
    Signed-off-by: Christian Ehrhardt <email address hidden>

 -- Bernd Zeimetz <email address hidden> Wed, 13 Jan 2021 19:20:14 +0100

Changed in gpsd (Ubuntu):
status: In Progress → Fix Released
Changed in gpsd (Debian):
status: Unknown → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.