Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

teslausb daemon.err ntpd[441]: error resolving pool 3.debian.pool.ntp.org: Temporary failure in name resolution (-3) #733

Open
aaronac8 opened this issue Jul 1, 2022 · 18 comments

Comments

@aaronac8
Copy link

aaronac8 commented Jul 1, 2022

Describe the problem

I have the following error:
teslausb daemon.err ntpd[441]: error resolving pool 3.debian.pool.ntp.org: Temporary failure in name resolution (-3)

How do I resolve this error, in simple terms, as I am a newbie?

Thank you

Device

Raspberry Pi Zero W

Car Model

Model Y

USB connection

Center console

Logs

diagnostics.txt

Additional information

No response

@marcone
Copy link
Owner

marcone commented Jul 1, 2022

That's just a message in a log file, which it will log when it's not connected to the network. Are you having any actual problems?

@aaronac8
Copy link
Author

aaronac8 commented Jul 1, 2022 via email

@marcone
Copy link
Owner

marcone commented Jul 1, 2022

Which day? (the diagnostics covers multiple days, so it would be helpful if to know which day something didn't work)

The diagnostics don't show anything wrong at first glance, except for your wifi being pretty slow. I'm guessing your car is parked far away from your access point or something.

@aaronac8
Copy link
Author

aaronac8 commented Jul 1, 2022 via email

@marcone
Copy link
Owner

marcone commented Jul 2, 2022

From the log it looks like the Pi was simply without power for most of that day.
It booted up on June 28, around 22:45:

Tue 28 Jun 22:17:03 EDT 2022: Starting archiveloop at 24.75 seconds uptime...
...
Tue 28 Jun 22:18:54 EDT 2022: Trying to set time...
Tue 28 Jun 22:47:33 EDT 2022: Time adjusted by 1719.692488 seconds after 0.310000 seconds

it then ran continuously until the evening of June 29, when it apparently lost power some time between 22:17 and 22:50.

When it next booted up, it was the late evening of June 30, just after 23:00:

Wed 29 Jun 22:17:03 EDT 2022: Starting archiveloop at 25.86 seconds uptime...
...
Wed 29 Jun 22:19:00 EDT 2022: Trying to set time...
Thu 30 Jun 23:05:53 EDT 2022: Time adjusted by 89212.759517 seconds after 0.350000 seconds

What brand/model sd card are you using by the way? Some of the operations I see in the log are much slower than on my own setup (a Raspberry Pi Zero W with a Sandisk Ultra 256 GB sd card)

@aaronac8
Copy link
Author

aaronac8 commented Jul 2, 2022 via email

@aaronac8
Copy link
Author

aaronac8 commented Jul 2, 2022 via email

@marcone
Copy link
Owner

marcone commented Jul 2, 2022

Can you attach the actual diagnostics file instead of copy/pasting? (the copy/paste above is incomplete)

@aaronac8
Copy link
Author

aaronac8 commented Jul 2, 2022 via email

@marcone
Copy link
Owner

marcone commented Jul 2, 2022

Lost connection again on 7/2/2022 at 3pm...see attached diagnostic file

Looks like you didn't actually attach the diagnostics file, but copy/pasted it, so it's incomplete again.

@aaronac8
Copy link
Author

aaronac8 commented Jul 2, 2022

diagnostics.txt

@marcone
Copy link
Owner

marcone commented Jul 2, 2022

It looks you "lost connection" well before that. You mentioned earlier that the Pi is always on because you have Sentry mode always on, correct? In that case, the hourly snapshot that teslausb takes of the drive image should contain new files every time, however:

Sat  2 Jul 07:38:43 EDT 2022: Waiting for archive to be unreachable...
Sat  2 Jul 07:40:09 EDT 2022: Sleeping before retry...
Sat  2 Jul 07:40:10 EDT 2022: Retrying...
Sat  2 Jul 08:34:26 EDT 2022: waiting up to 90 seconds for idle interval
Sat  2 Jul 08:36:08 EDT 2022: couldn't determine idle interval
Sat  2 Jul 08:36:09 EDT 2022: taking snapshot of cam disk in /backingfiles/snapshots/snap-009843
Sat  2 Jul 08:36:22 EDT 2022: took snapshot
Sat  2 Jul 08:36:27 EDT 2022: comparing new snapshot with /backingfiles/snapshots/snap-009842/snap.bin
Sat  2 Jul 08:36:27 EDT 2022: new snapshot is identical to previous one, discarding
Sat  2 Jul 09:34:38 EDT 2022: waiting up to 90 seconds for idle interval
Sat  2 Jul 09:36:20 EDT 2022: couldn't determine idle interval
Sat  2 Jul 09:36:21 EDT 2022: taking snapshot of cam disk in /backingfiles/snapshots/snap-009843
Sat  2 Jul 09:36:34 EDT 2022: took snapshot
Sat  2 Jul 09:36:38 EDT 2022: comparing new snapshot with /backingfiles/snapshots/snap-009842/snap.bin
Sat  2 Jul 09:36:39 EDT 2022: new snapshot is identical to previous one, discarding
Sat  2 Jul 10:34:48 EDT 2022: waiting up to 90 seconds for idle interval
Sat  2 Jul 10:36:30 EDT 2022: couldn't determine idle interval
Sat  2 Jul 10:36:30 EDT 2022: taking snapshot of cam disk in /backingfiles/snapshots/snap-009843
Sat  2 Jul 10:36:44 EDT 2022: took snapshot
Sat  2 Jul 10:36:48 EDT 2022: comparing new snapshot with /backingfiles/snapshots/snap-009842/snap.bin
Sat  2 Jul 10:36:48 EDT 2022: new snapshot is identical to previous one, discarding
Sat  2 Jul 11:34:52 EDT 2022: waiting up to 90 seconds for idle interval
Sat  2 Jul 11:36:34 EDT 2022: couldn't determine idle interval
Sat  2 Jul 11:36:34 EDT 2022: taking snapshot of cam disk in /backingfiles/snapshots/snap-009843
Sat  2 Jul 11:36:48 EDT 2022: took snapshot
Sat  2 Jul 11:36:53 EDT 2022: comparing new snapshot with /backingfiles/snapshots/snap-009842/snap.bin
Sat  2 Jul 11:36:53 EDT 2022: new snapshot is identical to previous one, discarding
Sat  2 Jul 12:34:55 EDT 2022: waiting up to 90 seconds for idle interval
Sat  2 Jul 12:36:37 EDT 2022: couldn't determine idle interval
Sat  2 Jul 12:36:38 EDT 2022: taking snapshot of cam disk in /backingfiles/snapshots/snap-009843
Sat  2 Jul 12:36:50 EDT 2022: took snapshot
Sat  2 Jul 12:36:55 EDT 2022: comparing new snapshot with /backingfiles/snapshots/snap-009842/snap.bin
Sat  2 Jul 12:36:55 EDT 2022: new snapshot is identical to previous one, discarding
Sat  2 Jul 13:34:57 EDT 2022: waiting up to 90 seconds for idle interval
Sat  2 Jul 13:36:40 EDT 2022: couldn't determine idle interval
Sat  2 Jul 13:36:40 EDT 2022: taking snapshot of cam disk in /backingfiles/snapshots/snap-009843
Sat  2 Jul 13:36:53 EDT 2022: took snapshot
Sat  2 Jul 13:36:57 EDT 2022: comparing new snapshot with /backingfiles/snapshots/snap-009842/snap.bin
Sat  2 Jul 13:36:57 EDT 2022: new snapshot is identical to previous one, discarding

indicates that nothing was being recorded during that entire time.
Then you apparently went for a drive around 13:47:

Sat  2 Jul 13:47:44 EDT 2022: Sleeping before retry...
Sat  2 Jul 13:47:45 EDT 2022: Retrying...
Sat  2 Jul 13:47:50 EDT 2022: Sleeping before retry...
Sat  2 Jul 13:47:51 EDT 2022: Retrying...
Sat  2 Jul 13:47:56 EDT 2022: Sleeping before retry...
Sat  2 Jul 13:47:57 EDT 2022: Retrying...
Sat  2 Jul 13:48:02 EDT 2022: Sleeping before retry...
Sat  2 Jul 13:48:03 EDT 2022: Retrying...
Sat  2 Jul 13:48:03 EDT 2022: Sleeping before retry...
Sat  2 Jul 13:48:04 EDT 2022: Retrying...
Sat  2 Jul 13:48:05 EDT 2022: Sleeping before retry...
Sat  2 Jul 13:48:06 EDT 2022: Retrying...
Sat  2 Jul 13:48:06 EDT 2022: Sleeping before retry...
Sat  2 Jul 13:48:07 EDT 2022: Retrying...
Sat  2 Jul 13:48:07 EDT 2022: Sleeping before retry...
Sat  2 Jul 13:48:08 EDT 2022: Retrying...
Sat  2 Jul 13:48:08 EDT 2022: Sleeping before retry...
Sat  2 Jul 13:48:09 EDT 2022: Retrying...
Sat  2 Jul 13:48:09 EDT 2022: Sleeping before retry...
Sat  2 Jul 13:48:10 EDT 2022: Retrying...
Sat  2 Jul 13:48:10 EDT 2022: Attempts exhausted.
Sat  2 Jul 13:48:10 EDT 2022: Archive is unreachable.

(if you didn't go for a drive, then something else happened that caused the archive server to become unreachable)

Some time during that drive teslaus took another snapshot, but again nothing had changed:

Sat  2 Jul 14:34:59 EDT 2022: waiting up to 90 seconds for idle interval
Sat  2 Jul 14:36:41 EDT 2022: couldn't determine idle interval
Sat  2 Jul 14:36:41 EDT 2022: taking snapshot of cam disk in /backingfiles/snapshots/snap-009843
Sat  2 Jul 14:36:55 EDT 2022: took snapshot
Sat  2 Jul 14:36:59 EDT 2022: comparing new snapshot with /backingfiles/snapshots/snap-009842/snap.bin
Sat  2 Jul 14:36:59 EDT 2022: new snapshot is identical to previous one, discarding

and then just as it was going to take another snapshot, you came back home:

Sat  2 Jul 15:35:01 EDT 2022: waiting up to 90 seconds for idle interval
Sat  2 Jul 15:35:27 EDT 2022: Archive is reachable.
Sat  2 Jul 15:35:27 EDT 2022: Trying to set time...
Sat  2 Jul 15:35:27 EDT 2022: Time adjusted by 0.004553 seconds after 0.260000 seconds
Sat  2 Jul 15:35:27 EDT 2022: not keeping car awake.
Sat  2 Jul 15:35:48 EDT 2022: taking snapshot of cam disk in /backingfiles/snapshots/snap-009843
Sat  2 Jul 15:36:01 EDT 2022: took snapshot
Sat  2 Jul 15:36:05 EDT 2022: comparing new snapshot with /backingfiles/snapshots/snap-009842/snap.bin
Sat  2 Jul 15:36:06 EDT 2022: new snapshot is identical to previous one, discarding
Sat  2 Jul 15:36:08 EDT 2022: Disconnecting usb from host...
Sat  2 Jul 15:36:08 EDT 2022: Disconnected usb from host.
Sat  2 Jul 15:36:09 EDT 2022: mass storage process not active, OK to write
Sat  2 Jul 15:36:09 EDT 2022: taking snapshot of cam disk in /backingfiles/snapshots/snap-009843
Sat  2 Jul 15:36:13 EDT 2022: Running fsck on /backingfiles/cam_disk.bin...
Sat  2 Jul 15:36:13 EDT 2022: | fsck from util-linux 2.33.1
Sat  2 Jul 15:36:29 EDT 2022: took snapshot
Sat  2 Jul 15:36:33 EDT 2022: | fsck.fat 4.1 (2017-01-24)
Sat  2 Jul 15:36:33 EDT 2022: | /dev/loop1p1: 1704 files, 3848132/8379619 clusters
Sat  2 Jul 15:36:33 EDT 2022: Finished fsck on /backingfiles/cam_disk.bin.
Sat  2 Jul 15:36:33 EDT 2022: Running fsck on /backingfiles/music_disk.bin...
Sat  2 Jul 15:36:34 EDT 2022: | fsck from util-linux 2.33.1
Sat  2 Jul 15:36:37 EDT 2022: comparing new snapshot with /backingfiles/snapshots/snap-009842/snap.bin
Sat  2 Jul 15:36:37 EDT 2022: new snapshot is identical to previous one, discarding
Sat  2 Jul 15:36:46 EDT 2022: | fsck.fat 4.1 (2017-01-24)
Sat  2 Jul 15:36:46 EDT 2022: | /dev/loop1p1: 6080 files, 864219/1638447 clusters
Sat  2 Jul 15:36:46 EDT 2022: Finished fsck on /backingfiles/music_disk.bin.
Sat  2 Jul 15:36:46 EDT 2022: Archiving...
Sat  2 Jul 15:36:46 EDT 2022: Ensuring cam archive is mounted...
Sat  2 Jul 15:36:47 EDT 2022: Mounting /mnt/archive...
Sat  2 Jul 15:36:47 EDT 2022: Mounted /mnt/archive.
Sat  2 Jul 15:36:47 EDT 2022: Ensured cam archive is mounted.
Sat  2 Jul 15:36:47 EDT 2022: Ensuring music archive is mounted...
Sat  2 Jul 15:36:47 EDT 2022: Mounting /mnt/musicarchive...
Sat  2 Jul 15:36:47 EDT 2022: Mounted /mnt/musicarchive.
Sat  2 Jul 15:36:47 EDT 2022: Ensured music archive is mounted.
Sat  2 Jul 15:36:47 EDT 2022: Checking saved folder count...
Sat  2 Jul 15:36:47 EDT 2022: Ensuring cam file is mounted...
Sat  2 Jul 15:36:48 EDT 2022: Mounting /mnt/cam...
Sat  2 Jul 15:36:48 EDT 2022: Mounted /mnt/cam.
Sat  2 Jul 15:36:48 EDT 2022: Ensured cam file is mounted.
Sat  2 Jul 15:36:54 EDT 2022: There are 0 event folder(s) with 0 file(s) and 0 track mode file(s) to move.  0 short recording(s) will be skipped.
Sat  2 Jul 15:36:54 EDT 2022: cleaning cam mount
Sat  2 Jul 15:36:59 EDT 2022: done cleaning cam mount
Sat  2 Jul 15:36:59 EDT 2022: Trimming free space in /mnt/cam, which has 3841 extents
Sat  2 Jul 15:37:00 EDT 2022: Trim complete, image now has 3841 extents
Sat  2 Jul 15:37:00 EDT 2022: Unmounting /mnt/cam...
Sat  2 Jul 15:37:01 EDT 2022: Unmounted /mnt/cam.
Sat  2 Jul 15:37:01 EDT 2022: Finished archiving.
Sat  2 Jul 15:37:01 EDT 2022: Copying music...
Sat  2 Jul 15:37:01 EDT 2022: Starting music sync...
Sat  2 Jul 15:37:01 EDT 2022: Ensuring music backing file is mounted...
Sat  2 Jul 15:37:01 EDT 2022: Mounting /mnt/music...
Sat  2 Jul 15:37:01 EDT 2022: Mounted /mnt/music.
Sat  2 Jul 15:37:01 EDT 2022: Ensured music drive is mounted.
Sat  2 Jul 15:37:01 EDT 2022: Syncing music from archive...
Sat  2 Jul 15:37:40 EDT 2022: Copied 0 music file(s), deleted 0, skipped 5693 previously-copied files, and encountered 0 errors.
Sat  2 Jul 15:37:40 EDT 2022: Trimming free space in /mnt/music, which has 171 extents
Sat  2 Jul 15:37:41 EDT 2022: Trim complete, image now has 171 extents
Sat  2 Jul 15:37:41 EDT 2022: Unmounting /mnt/music...
Sat  2 Jul 15:37:41 EDT 2022: Unmounted /mnt/music.
Sat  2 Jul 15:37:41 EDT 2022: Finished copying music.
Sat  2 Jul 15:37:41 EDT 2022: unmounting /mnt/archive
Sat  2 Jul 15:37:41 EDT 2022: Truncating log...
Sat  2 Jul 15:37:41 EDT 2022: Connecting usb to host...
Sat  2 Jul 15:37:42 EDT 2022: Connected usb to host.
Sat  2 Jul 15:37:47 EDT 2022: Waiting for archive to be unreachable...

The only thing out of the ordinary is that the car isn't actually writing anything to the drive. I don't know why it would be doing that (though it certainly has nothing to do with the "temporary failure in name resolution" message). If it's a bad cable you wouldn't be able to access the USB music files in the car and the dashcam viewer in the car would show nothing, so that's something to check.

@aaronac8
Copy link
Author

aaronac8 commented Jul 2, 2022

I brought the teslausb into my home and connected to my PC and the music and cam drives are recognized with the same cable I use in the car, even though they were not recognized in the car. Attached new diagnostic file:
diagnostics.txt

@aaronac8
Copy link
Author

aaronac8 commented Jul 2, 2022

I just tried a:
sudo -i
/root/bin/setup-teslausb upgrade

to see if that will help. Not sure what else to do

@aaronac8
Copy link
Author

aaronac8 commented Jul 3, 2022 via email

@marcone marcone closed this as completed Jul 6, 2022
@marcone marcone reopened this Jul 6, 2022
@marcone
Copy link
Owner

marcone commented Jul 6, 2022

sorry, meant to keep this open as a reminder to try and do something about the "temporary failure in name resolution" message, since while benign, it makes people think something is wrong.

@SpeedlimitsB
Copy link

Hi @marcone ,
many thanks for you effort ,

Did you fix already the error resolving pool 3.debian.pool.ntp.org: Temporary failure in name resolution ?

regards

@marcone
Copy link
Owner

marcone commented Jan 9, 2024

No, it hasn't been a priority because it's not an actual problem.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants