Re: New SHM

[Miroslav Lichvar]

On Mon, Jan 23, 2023 at 01:32:58AM -0800, Hal Murray wrote:
> mlichvar@redhat.com said:
> > gpsd would write to ".sock" as expected, but chronyd/ntpd would need to be
> > configured to use ".sock1" and the monitoring application would read from
> > ".sock2". That's pretty bad when compared ntpshmmon, which 
> 
> Would it be reasonable for gpsd to setup another socket when the first one is 
> busy?

It's a datagram Unix domain socket, not a stream socket. It's like UDP
vs TCP. The socket is bound by the server and there can be multiple
clients sending messages to the same server socket (no need for
listen()/accept() etc). The client doesn't have to bind its own
socket. Unlike UDP, connect() makes a real connection, which works
after dropping root privileges (it doesn't just set the default
destination address). The client will get an error on connect() if the
server socket doesn't exist or is no longer bound by the server, but
it will not get an error when something else is already connected.

> Plan B is for gpsd to always open 2 and ntpshmmon be hardwried to use the 
> second one.

Yes, there could be a separate socket designated for monitoring
purposes. The monitoring program would need to be started before gpsd
in order to be able to connect to it as root. This would mean gpsd
would need to try to connect to four different sockets per device (two
PPS and two non-PPS sockets).

There are few different things to check if it doesn't work:
- Does the server socket exist? That's easy to verify with ls
- Is the server bound to that socket? Can be verified with lsof/ss/netstat
- Is something sending messages to the socket? This seems to be the
  difficult thing to verify. Debug output should make that clear.

-- 
Miroslav Lichvar