Re: [gpsd-dev] [ntp:hackers] NTP Release Candidate 4.2.8p1-RC1 Released

[Hal Murray]

address@hidden said:
> Looks like gpsd gave a few nice TPV and PPS's and then the client just went
> away: 

There should be a version string in the startup dance.

----

Thanks for bringing this up.

We have a mess here.  I don't know what's going on.  I'm seeing similar tangles.

All I did to start it was to set flag3 in the JSON servers (disable 
anti-verbose logging) so I could get a better log file to send you and restart 
ntpd.


I'm using 2 devices.  I'm not getting any SHM data.

gpsmon said:
Read error from device


I killed ntpd to simplify things.

Can you make sense of this?

Proto Recv-Q Send-Q Local Address           Foreign Address         State      
tcp        0      0 localhost:gpsd          localhost:32911         SYN_RECV   
tcp        0      0 localhost:gpsd          localhost:32912         SYN_RECV   
tcp        0      0 localhost:gpsd          localhost:32910         SYN_RECV   
tcp        0     11 localhost:32908         localhost:gpsd          FIN_WAIT1  
tcp       11      0 localhost:gpsd          localhost:32874         CLOSE_WAIT 
tcp       11      0 localhost:gpsd          localhost:32871         CLOSE_WAIT 
tcp       11      0 localhost:gpsd          localhost:32872         CLOSE_WAIT 
tcp        0     11 localhost:32907         localhost:gpsd          FIN_WAIT1  
tcp        0     11 localhost:32912         localhost:gpsd          FIN_WAIT1  
tcp        0     11 localhost:32911         localhost:gpsd          FIN_WAIT1  
tcp       11      0 localhost:gpsd          localhost:32873         CLOSE_WAIT 
tcp       11      0 localhost:gpsd          localhost:32869         CLOSE_WAIT 
tcp        0     29 localhost:32910         localhost:gpsd          ESTABLISHED
tcp       11      0 localhost:gpsd          localhost:32870         CLOSE_WAIT 

After a while:
Proto Recv-Q Send-Q Local Address           Foreign Address         State      
tcp       11      0 localhost:gpsd          localhost:32874         CLOSE_WAIT 
tcp       11      0 localhost:gpsd          localhost:32871         CLOSE_WAIT 
tcp       11      0 localhost:gpsd          localhost:32872         CLOSE_WAIT 
tcp       11      0 localhost:gpsd          localhost:32873         CLOSE_WAIT 
tcp       11      0 localhost:gpsd          localhost:32869         CLOSE_WAIT 
tcp       11      0 localhost:gpsd          localhost:32870         CLOSE_WAIT 

That looks like gpsd isn't processing input.   ??

Yes, I'm running with HEAD, from an hour or so ago, after Eric's recent message.

I guess it's time to fire up gdb.

kill didn't kill it.  This feels like the same bug I had the other day.

It took a couple of tries restarting ntpd, but I got this:

(gdb) run -n -N /dev/gps0 /dev/gps1
Starting program: /home/murray/gpsd/work/gpsd -n -N /dev/gps0 /dev/gps1
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
[New Thread 0x7ffff6743700 (LWP 10759)]
[New Thread 0x7ffff5f42700 (LWP 10762)]

Program received signal SIGPIPE, Broken pipe.
[Switching to Thread 0x7ffff6743700 (LWP 10759)]
0x00007ffff72436af in __libc_send (fd=8, buf=0x7ffff6740ca0, n=117, flags=0)
    at ../sysdeps/unix/sysv/linux/x86_64/send.c:31
31        ssize_t result = INLINE_SYSCALL (sendto, 6, fd, buf, n, flags, NULL,
(gdb) 



-- 
These are my opinions.  I hate spam.