gpsd: add wrapper script for hotplug/respawn handling

[osedlbauer]

📦 Package Details

Maintainer: @psidhu (MIA)
CC: @PolynomialDivision @BKPepe @feckert

Description:
Gpsd needs some time to create its Unix socket after the process starts. The hotplug call in service_started() is triggered too early, before the socket is ready, causing failures in scripts that depend on it.

Additionally, when gpsd crashes and procd respawns it, service_started() is not called again, so no hotplug event is emitted on respawn. Therefore scripts listening for gpsd availability miss the STARTED event.

This pr ensures the hotplug call waits for the socket to appear, so dependent scripts reliably see the STARTED event, even after respawns.

---

🧪 Run Testing Details

• OpenWrt Target/Subtarget: mediatek/filogic
• OpenWrt Device: bananapi_r4

---

✅ Formalities

• I have reviewed the CONTRIBUTING.md file for detailed contributing guidelines.

[pprindeville]

I'm wondering if the forking parent shouldn't hold off returning until after the socket has been created and whatever other initialization needs to happen...

[osedlbauer]

I'm not sure I understand the concern correctly.

We pass the command flags via the wrapper to gpsd. We call gpsd with the -N flag (no daemonize):

procd_set_param command "$PROG" -N -n

Looking at the gpsd source code, without -N it would fork into the background after socket initialization. With -N, it stays in the foreground and does not signal when initialization is complete.

The wrapper backgrounds gpsd with & to maintain control over the process while waiting for the socket and triggering hotplug. The wrapper itself exits only when gpsd exits (or when receiving SIGTERM from procd), so procd can properly detect crashes and respawn it.

[pprindeville]

With -N, it stays in the foreground and does not signal when initialization is complete.

Ah, okay, got it. So unless there's an external sentinel (like a domain socket in the filesystem) there's no other way to detect readiness of the service...