Slappy

Members
  • Posts

    6
  • Joined

  • Last visited

Slappy's Achievements

Newbie

Newbie (1/14)

0

Reputation

  1. One more data point... I made my local ubuntu VM an ntp server for my unraid box, and it was able to connect and sync just fine. So it sppears that I can't connect to servers outside the LAN and get ntp to move beyond .INIT., so that rules out some sort of generalized network misconfiguration preventing NTP from working on the unraid side. This serves as a temporary fix but I'd sure like to get NTP to sync with external servers.
  2. From the "curiouser and curiouser" files, I have another server running as a VM on my unraid box that was migrated from physical hardware long ago. It's running the default ubuntu NTP setup, and NTP is connecting to the ubuntu pool servers just fine, so that seems to eliminate a network configuration problem or port blocking somewhere, and isolate this to a unraid problem. The only thing I can think of is that I have bridged interfaces... would that create a problem? ntpq -p from ubuntu VM on the same LAN: dude@server:~$ ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== 0.ubuntu.pool.n .POOL. 16 p - 64 0 0.000 0.000 0.000 1.ubuntu.pool.n .POOL. 16 p - 64 0 0.000 0.000 0.000 2.ubuntu.pool.n .POOL. 16 p - 64 0 0.000 0.000 0.000 3.ubuntu.pool.n .POOL. 16 p - 64 0 0.000 0.000 0.000 ntp.ubuntu.com .POOL. 16 p - 64 0 0.000 0.000 0.000 -muug.ca 216.218.254.202 2 u 449 1024 377 46.959 1.997 0.662 +ntp-ca.padevsof 97.183.206.88 2 u 528 1024 377 40.260 1.904 0.428 *voipmonitor.wci 66.220.9.122 2 u 768 1024 377 73.923 0.002 0.861 -time.nullrouten 132.163.97.1 2 u 631 1024 377 67.773 2.113 0.214 +time.cloudflare 10.106.8.9 3 u 655 1024 377 27.078 -0.763 0.118
  3. Hello, For some reason NTP is always the bane of my existence, and unraid seems to be no exception. After being running for 90 days without a reboot I noticed the clock on my automation system (unraid docker) was a couple minutes off, which upon further debugging led me to discover the clock on unraid (verified with 'date' command) was off. I verified NTP was running with 'ntpq -p' and i get the following using the default configuration, and the default pool.ntp.org severs (pool, 0.pool, etc): :~# ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== LOCAL(0) .LOCL. 10 l 6 64 1 0.000 +0.000 0.000 pscolka.of.pl .INIT. 16 u - 64 0 0.000 +0.000 0.000 laika.paina.net .INIT. 16 u - 64 0 0.000 +0.000 0.000 138.68.201.49 ( .INIT. 16 u - 64 0 0.000 +0.000 0.000 198.255.68.106 .INIT. 16 u - 64 0 0.000 +0.000 0.000 If I restart NTP I get the following in syslog: Aug 18 12:39:35 icecube root: Stopping NTP daemon... Aug 18 12:39:36 icecube ntpd[32271]: ntpd 4.2.8p15@1.3728-o Tue Oct 20 18:42:21 UTC 2020 (1): Starting Aug 18 12:39:36 icecube ntpd[32271]: Command line: /usr/sbin/ntpd -g -u ntp:ntp Aug 18 12:39:36 icecube ntpd[32271]: ---------------------------------------------------- Aug 18 12:39:36 icecube ntpd[32271]: ntp-4 is maintained by Network Time Foundation, Aug 18 12:39:36 icecube ntpd[32271]: Inc. (NTF), a non-profit 501(c)(3) public-benefit Aug 18 12:39:36 icecube ntpd[32271]: corporation. Support and training for ntp-4 are Aug 18 12:39:36 icecube ntpd[32271]: available at https://www.nwtime.org/support Aug 18 12:39:36 icecube ntpd[32271]: ---------------------------------------------------- Aug 18 12:39:36 icecube ntpd[32273]: proto: precision = 0.064 usec (-24) Aug 18 12:39:36 icecube ntpd[32273]: basedate set to 2020-10-08 Aug 18 12:39:36 icecube ntpd[32273]: gps base set to 2020-10-11 (week 2127) Aug 18 12:39:36 icecube ntpd[32273]: Listen normally on 0 lo 127.0.0.1:123 Aug 18 12:39:36 icecube ntpd[32273]: Listen normally on 1 br0 192.168.XXX.XXX:123 Aug 18 12:39:36 icecube ntpd[32273]: Listen normally on 2 lo [::1]:123 Aug 18 12:39:36 icecube ntpd[32273]: Listening on routing socket on fd #19 for interface updates Aug 18 12:39:36 icecube ntpd[32273]: kernel reports TIME_ERROR: 0x2041: Clock Unsynchronized Aug 18 12:39:36 icecube ntpd[32273]: kernel reports TIME_ERROR: 0x2041: Clock Unsynchronized Aug 18 12:39:36 icecube root: Starting NTP daemon: /usr/sbin/ntpd -g -u ntp:ntp ntpq -p stays stuck in .INIT. for days/weeks so it's not a matter of "just wait a bit longer." I've tried the following to debug: Restart NTPD on the command line; reboot server. Same symptoms Try alternate NTP servers, including entering an IP address from the ntp.org pool servers. Same .INIT. Opened port 123 for UDP on my router and mapped to my unraid server at 192.168.XXX.XXX which is the br0 interface it should be listening on. Verified UDP connectivity from the outside world using an online port checker (UDP Port Checker Online - Open Port) which reports that port 123 is open when hit from my external IP address Checked that I could hit port 123 from another server on the lan using nmap. Reported success Drank 2 Manhattans and cursed the NTP gods. That felt good but didn't really help much Anyone have any ideas?
  4. FYI I started having problems (again) with the Toronto server, and my logs would repeatedly end with "Peer connection Initiated" and then it would go through the connect dance again. I used the config generator above (selected Linux and Nextgen), dropped it in the openvpn directory and the container was able to connect. This docker has been a bastion of reliability until the last week... hopefully gets itself sorted.
  5. Same problem here. They don't seem to do anything. I wonder if there's a way to pass a parameter that overrides the default setting since I'd like to have NPM function on my LAN more than my WAN.
  6. Same issue here. Can't find "letsencrypt" and have tried several permutations of the search. Other images show up but not letsencrypt.