Pi lost some capability

[eel9]

I've been working on a new R pi 3B+ for the last month or so. I'm running Raspbian stretch. I've added an Adafruit ultimate GPS. I'm supplying power via the 5 V pin. I'm running headless and use VNC or putty from a Windows 10 laptop. I have an RTL SDR connected to a USB port.
This morning while debugging my java application I started receiving an error message after typing "java -jar filename.jar", the message is "unable to access jarfile filename.jar". After a few Pi reboots and repowers nothing changed. I even rebooted the laptop. I even tried to run an old HelloWord.jar file and got the same error. Next was to reimage the SD card to an image done 3 days ago. I received the same error with the HelloWord.jar. At some point later I noticed ntp wasn't working properly. It was receiving GPS time but was not sync'ing to the PPS signal nor sync'ing to GPS messages. Both of these (java & ntp) seemingly unrelated programs stopped working around the same time. Next, I got a second SD card and loaded the same 3 day old image on to it. This resulted in the same behavior where I could not run java and ntp wasn't syncing. I then went out an purchased a brand new Pi 3B+, attached the Ultimate GPS and power, placed the 1st SD card in the slot, powered up and this new Pi behaves identically to the 1st Pi. Both ntp and java are not working. I powered off the 2nd Pi, put the 2nd SD card into the 1st Pi, did NOT connect the Ultimate GPS, applied power via USB, and got the same error when trying to run java.
I'm left with nothing else to try and looking for any help that can solve this dilemma.

[DougieLawson]

Try a fresh new SDCard with a fresh new copy of Raspbian. Copy your Java stuff over and see if it runs OK.

Then look at copying other data & programs over from the broken system.

Your existing SDCard may have reached end of life.

[eel9]

Would a fresh install on a brand new SD be any different than writing a prior working image to the same brand new SD card? The 'old' SD card is only a couple months old, would you expect this age to be at it's end of life?

[DougieLawson]

Yes because it won't start out broken. You're not going to find a root cause if your backup from days ago is bad. So building a new system is best use of your time and effort.

[eel9]

Newest SD card, fresh install of Raspbian stretch lite (2018-11-13) with ssh enabled, connected via ethernet, sudo apt-get update, sudo apt-get upgrade, sudo apt-get install oracle-java8-jdk, copied helloworld.jar, java -jar helloworld.jar - same results: unable to access jar file.

Next step?

Something else I thought of. One common item between the two SD cards and two RPi's is the Adafruit Ultimate GPS. It has been connected to both RPi's. I'm not a CS engineer, but is it possible the Ultimate GPS has suffered a failure that has caused a downstream failure on the RPi's? And this failure doesn't completely break the RPi, but cripples any software that utilizes a specific hardware they need.

[DougieLawson]

How are you copying that Jar file. If you binary FTP it to your laptop does it run on there?

[eel9]

Well, I'm starting to feel a little (maybe a lot) embarrassed.

I tried running helloworld.jar on the laptop and got the same error. I recall (maybe incorrectly) to run jar files I needed to be one directory up from the jar file. For example, if the jar file was located at home/pi/helloworld/dist/helloworld.jar, I would navigate to home/pi/helloworld and type java -jar helloworld.jar. But if I navigate to home/pi/helloworld/dist and run the same command, then the jar file is executed. Also, it runs on the laptop by being in the same directory as the jar file.

Now to see if I can figure out why ntp isn't running correctly.

[eel9]

Here's whats going on with ntp and what makes me think something is wrong.

sat@RPiSatWx:~ $ ntpq -crv -pn
associd=0 status=c016 leap_alarm, sync_unspec, 1 event, restart,
version="ntpd 4.2.8p12@1.3728 Sat Dec 15 06:28:21 UTC 2018 (1)",
processor="armv7l", system="Linux/4.14.79-v7+", leap=11, stratum=16,
precision=-21, rootdelay=0.000, rootdisp=49.830, refid=INIT,
reftime=(no time),
clock=dfe1738a.074894a8 Thu, Jan 10 2019 7:32:26.028, peer=0, tc=3,
mintc=3, offset=0.000000, frequency=-5.341, sys_jitter=0.000000,
clk_jitter=0.000, clk_wander=0.000

remote refid st t when poll reach delay offset jitter
==============================================================================
192.168.1.255 .BCST. 16 B - 64 0 0.000 0.000 0.000
127.127.22.0 .PPS. 0 l - 8 0 0.000 0.000 0.000
127.127.28.0 .GPS. 1 l - 1024 0 0.000 0.000 0.000
127.127.28.2 .SHM2. 0 l - 8 0 0.000 0.000 0.000

This is after the pi has been running for more than an hour. In the past I would see o, +, *, or x preceding the IPV4 addresses, typically having a o on the PPS line. Also, the delay, offset, and jitter values would be non-zero.


Next,
sat@RPiSatWx:~/ntp-4.2.8p12 $ sudo ppstest /dev/pps0
trying PPS source "/dev/pps0"
found PPS source "/dev/pps0"
ok, found 1 source(s), now start fetching data...
source 0 - assert 1547105790.243436480, sequence: 4746 - clear 0.000000000, sequence: 0
source 0 - assert 1547105791.243435930, sequence: 4747 - clear 0.000000000, sequence: 0
source 0 - assert 1547105792.243436266, sequence: 4748 - clear 0.000000000, sequence: 0
source 0 - assert 1547105793.243436810, sequence: 4749 - clear 0.000000000, sequence: 0
^C

Appears to be correct. So it looks like the PPS is working.

Is there anything else I should check?

[eel9]

Progress on the ntp front. A couple weeks ago in the ntp.conf file I changed a few items after reading Meinberg's site and interpreting them as not necessary.

The items were:
server 127.127.22.0 minpoll 3 maxpoll 3 true
fudge 127.127.28.0 flag1 1 time1 0.500 refid GPS stratum 1
fudge 127.127.28.2 flag1 1 refid SHM2
tos mindist 0.5

I changed them to:
server 127.127.22.0 minpoll 3 maxpoll 3
fudge 127.127.28.0 time1 0.500 refid GPS stratum 1
fudge 127.127.28.2 refid SHM2
#tos mindist 0.5

After changing them back to the original and restarting ntp, I'm now getting good results from ntpq
ssocid=0 status=0115 leap_none, sync_pps, 1 event, clock_sync,
version="ntpd 4.2.8p10@1.3728-o Sat Mar 10 18:03:33 UTC 2018 (1)",
processor="armv7l", system="Linux/4.14.79-v7+", leap=00, stratum=1,
precision=-21, rootdelay=0.000, rootdisp=500.000, refid=PPS,
reftime=dfe68954.6f6180fe Mon, Jan 14 2019 4:06:44.435,
clock=dfe68955.003db41b Mon, Jan 14 2019 4:06:45.000, peer=23114, tc=3,
mintc=3, offset=-0.023799, frequency=-4.328, sys_jitter=0.002008,
clk_jitter=0.069, clk_wander=0.017
remote refid st t when poll reach delay offset jitter
==============================================================================
192.168.1.255 .BCST. 16 B - 64 0 0.000 0.000 0.000
o127.127.22.0 .PPS. 0 l 1 8 377 0.000 -0.024 0.002
*127.127.28.0 .GPS. 1 l 624 1024 1 0.000 4.966 0.000
+127.127.28.2 .SHM2. 0 l 7 8 377 0.000 -0.024 0.002

I hate it when changes don't immediately make themselves known as being a problem.
Anyway, thanks for your help and I apologize if I wasted anyone's time.

[scruss]

Raspbian doesn't use ntpd directly any more. Take a look at systemd-timesyncd.service: man systemd-timesyncd.service