Error 403 on satnogs-client

I seem to have a similar issue. I have no symptoms, but the error keeps flooding the log. Upload and jobs run fine.

Feb 09 13:58:05 raspberrypi satnogs-client[340]: 2020-02-09 13:58:05,490 - satnogsclient.scheduler.tasks - ERROR - Bad status code: 403
Feb 09 13:58:06 raspberrypi satnogs-client[340]: 2020-02-09 13:58:06,731 - satnogsclient.scheduler.tasks - ERROR - Bad status code: 403
Feb 09 13:58:07 raspberrypi satnogs-client[340]: 2020-02-09 13:58:07,734 - satnogsclient.scheduler.tasks - ERROR - Bad status code: 403
Feb 09 13:58:09 raspberrypi satnogs-client[340]: 2020-02-09 13:58:09,468 - satnogsclient.scheduler.tasks - ERROR - Bad status code: 403
Feb 09 13:58:10 raspberrypi satnogs-client[340]: 2020-02-09 13:58:10,473 - satnogsclient.scheduler.tasks - ERROR - Bad status code: 403
Feb 09 13:58:24 raspberrypi satnogs-client[340]: 2020-02-09 13:58:24,438 - satnogsclient.scheduler.tasks - ERROR - Bad status code: 403
Feb 09 13:58:26 raspberrypi satnogs-client[340]: 2020-02-09 13:58:26,233 - satnogsclient.scheduler.tasks - ERROR - Bad status code: 403
Feb 09 13:58:27 raspberrypi satnogs-client[340]: 2020-02-09 13:58:27,149 - satnogsclient.scheduler.tasks - ERROR - Bad status code: 403
Feb 09 13:58:28 raspberrypi satnogs-client[340]: 2020-02-09 13:58:28,747 - satnogsclient.scheduler.tasks - ERROR - Bad status code: 403
Feb 09 13:58:30 raspberrypi satnogs-client[340]: 2020-02-09 13:58:30,630 - satnogsclient.scheduler.tasks - ERROR - Bad status code: 403

1 Like

@pierros @anders

I am seeing this exact error, though upload is working fine too. It started at Feb 8 18:16:38 UTC. It is occurring today too, and continuously since Feb 8. I don’t see anything earlier in the logs with that error.

Just a brainstorm: but they did kind of recently start re-requiring an API key for access to db. Maybe related, idk.

403 in client can be returned in two different cases.

  1. Client doesn’t use the right (Network) API Key. To find if this is your case, you need to check if your station in Network is online/testing or offline. If it is offline then you are in this case and you need to check your API Key.

  2. Client tries to upload something that has previously been uploaded and client hasn’t removed it locally. If you belong in this case you should find files from observations in /tmp/.satnogs/data/ directory which have been already uploaded in Network. In this case the problem can be solved by removing these files.

For better debugging and finding a solution on the last case, I’ve opened the following issues in satnogs-client repo:

PS API Key of SatNOGS DB has nothing to do with the client, it is only for accessing certain endpoints in DB. Client doesn’t request anything from DB.

1 Like

I had these files in /tmp/.satnogs/data

-rw-r--r-- 1 satnogs satnogs   90112 Feb 11 09:18 receiving_satnogs_1682897_2020-02-11T16-18-08.out
-rw-r--r-- 1 satnogs satnogs  848700 Feb 11 09:18 receiving_waterfall_1682897_2020-02-11T16-18-08.dat
-rw-r--r-- 1 satnogs satnogs 6614702 Feb  8 11:12 satnogs_1667499_2020-02-08T18-06-01.ogg
-rw-r--r-- 1 satnogs satnogs 4015730 Feb 11 09:17 satnogs_1683035_2020-02-11T16-13-56.ogg
-rw-r--r-- 1 satnogs satnogs 1681148 Feb 11 09:18 waterfall_1683035_2020-02-11T16-13-56.png

I’ve removed the above files. The incomplete directory was empty. The API key is correct.

Edit: list files from correct pi…

As far I can check, 1667499 had already audio file and 1683035 had already audio and waterfall files, so 99,9999% this is why you got 403 errors. Also 1667499 audio file creation date fits with the Feb 8th when the issue was started.

2 Likes

Ya, @fredy deleting those files (specifically satnogs_1667499_2020-02-08T18-06-01.ogg) looks like it cleaned up the 403 errors. Thanks!

1 Like

Thanks for the tip fredy! I figured out I had misconfigured paths - a reset to default paths fixed it for me.

Thanks!

2 Likes