GeoClue not working unless Qt app is launched after gps-share and geoclue agent

Technical Support
, , ,
1

Hi all,
I’m facing an issue with location services provided by GeoClue.

My Qt app uses positionSource to get GPS data. The GPS hardware is working correctly via gps-share, and geoclue-agent is working well too. However, the location only works if I launch my Qt app after both gps-share and geoclue-agent are already running.

The problem is: I’m launching my Qt app very early in the boot process using a script (even before systemd), so I cannot simply “launch it after” these services. Unfortunately, when the app starts first, it fails to get location updates and never catches up, even after GeoClue and gps-share are ready.

I tried handling this on the Qt side by checking availability and retrying startUpdates() later, but it doesn’t resolve the issue. The app seems unable to reconnect or get notified once GeoClue becomes ready.

My questions are:

  • Is there an environment variable or D-Bus-related config I can set to link my Qt app with GeoClue regardless of start order?
  • Can I reliably start gps-share and geoclue-agent earlier (before my app) within the script?
  • Or, is there a qt-based way to ensure my app waits for GeoClue and gps-share to be fully initialized

NB: as i said my qt app isn’t launched with a service but with a script and a a kernel command line init=/home/root/launch.sh

#!/bin/sh

# Mount essential filesystems 


export DBUS_SYSTEM_BUS_ADDRESS=unix:path=/run/dbus/system_bus_socket


# Kernel modules

# Qt environment



# Start application


# Optionally replace script with systemd if needed
exec /lib/systemd/systemd

and yes i also tried this export DBUS_SYSTEM_BUS_ADDRESS=unix:path=/run/dbus/system_bus_socket and didn’t work

so currently i am trying to launch gps-share and geoclue agent in the same script if you have any idea how to do so

2

Hi, I’m the Toradex AI Assistant.

I might make mistakes. Our support team will step in if needed. If I answered your question, please tick the “Solution” checkbox. For follow-up questions to me, please use @ToradexAI in your post.

Did you like my answer? :+1: :-1:

Hello! Thank you for your detailed question.

This is a common challenge when working with service dependencies on embedded Linux, especially when launching applications before the standard systemd startup sequence. Here are some general suggestions when integrating Qt with GeoClue and external GPS sources on Toradex hardware:

1. Service Dependency with systemd (Recommended Approach)

The best way to ensure startup order in Linux is to use systemd unit files with the appropriate dependencies. Even if you are not currently using systemd to start your app, you should consider migrating to this approach, as it offers precise control using directives such as After= and Requires=.

Example—A service unit for your Qt app:

[Unit]
Description=My Qt App
After=geoclue.service gps-share.service
Requires=geoclue.service gps-share.service

[Service]
ExecStart=/usr/bin/my-qt-app
Restart=on-failure

[Install]
WantedBy=multi-user.target

This ensures gps-share and GeoClue are started before your app.

2. Handling Order in Early Boot Scripts

If you must remain outside systemd, your script should explicitly launch gps-share and geoclue-agent, then wait (check for D-Bus service registration or port availability) before starting your Qt app.

For example:

gps-share &
geoclue-agent &
sleep 5  # or implement a loop that checks service availability
my-qt-app

A more robust approach is to poll with a command like:

while ! dbus-send --system --dest=org.freedesktop.GeoClue2 --type=method_call /org/freedesktop/GeoClue2/Manager org.freedesktop.DBus.Peer.Ping; do
  sleep 1
done
my-qt-app

3. Qt Application-side Workarounds

QtLocation’s positionSource generally expects the service to be available at initialization. The API typically doesn’t allow for late binding to new GPS providers. Retrying startUpdates() sometimes helps if the backend handles reconnections well, but as you noticed, it doesn’t always work.

  • There isn’t a straightforward environment variable that forces dynamic (re-)connection after GeoClue starts.
  • Make sure your application, when failing to get a position, continues to retry at intervals rather than giving up entirely. However, this is not always robust, depending on the Qt backend implementation.

4. Additional References

  • Toradex Community — Search for GPS, Qt, and GeoClue topics for community wisdom.
  • Toradex GitHub — Look for reference projects or scripts for service startup.

Summary

  • systemd ordering is the most reliable and maintainable.
  • If scripting, ensure the script robustly waits for GeoClue and gps-share to be ready before starting Qt.
  • Qt’s built-in handling is limited in this scenario; app-level retry logic may work but is not always reliable.

If you need example unit files or script snippets for Toradex platforms, let me know!

Best regards,
Toradex AI Assistant.

3

Hi @rania !

From your question, I understand that you have all your hardware working correctly, and now you need to find a way to make them work for your application according to your project’s requirements, correct?

If yes, your question is very application-development related, which is out-of-scope of Toradex Technical Support.

If you need further help, I recommend your on (or more) of the following:

Also, the answer from ToradexAI is very helpful. You can get more help from it by tagging it in your answer.

Best regards,