starred/dehydrated
1
0
Fork 0
mirror of https://github.com/dehydrated-io/dehydrated.git synced 2026-01-13 15:13:33 +01:00
Code Issues 79 Packages Projects Releases 10 Wiki Activity

Handle slow connections better (curl timeout) #156

New Issue
Closed
opened 2025-12-29 00:26:09 +01:00 by adam · 3 comments
adam commented 2025-12-29 00:26:09 +01:00
Owner
Copy Link

Originally created by @joachimtingvold on GitHub (Oct 13, 2016).

Hi,

So, I had some issues with LE/dehydrated. I made a post on the LE Community.

The issue is specific to IPv6 (in my case), causing the curl returned with 35 error. Forcing dehydrated (and in turn, curl) to use IPv4 (with --ipv4), "solved" the issue. There are no noticable issues with our IPv6 connectivity, and RTT is also low towards the LE servers (both on IPv4 and IPv6), but curl still ends up using a lot of time on some of the queries over IPv6.

Not sure if this is really an issue with LE's servers, but nontheless dehydrated should probably handle those errors more gracefully? I.e. by either a) retry the connection N times when it's error 35, or b) extend the timeout? (afaik the default timeout of curl is 0, which is "forever", so not sure why error 35 is even the issue).

My ugly measurement setup;

i=1;while true; do echo "date: Measurement #$i"; timelol="{ time curl -s6 https://acme-staging.api.letsencrypt.org/acme/new-authz >/dev/null; } 2>&1 | grep real | perl -wple 's,real\s+,,g'"; seconds=echo $timelol|cut -d'.' -f1|perl -wple 's,0m,,' ; if [ $seconds -gt 5 ]; then echo "date: Long measurement (#$i): $timelol"; fi; let i="i+1"; sleep 1; done

Did about 600 measurements, and ~60 of them had 5+ seconds. Most of them well below 30 seconds, and all of them below 60 seconds.

Any takers?

Originally created by @joachimtingvold on GitHub (Oct 13, 2016). Hi, So, I had some issues with LE/dehydrated. I made a [post on the LE Community](https://community.letsencrypt.org/t/curl-returned-with-35-anti-replay-nonce-seems-ipv6-related/21026). The issue is specific to IPv6 (in my case), causing the `curl returned with 35` error. Forcing dehydrated (and in turn, curl) to use IPv4 (with `--ipv4`), "solved" the issue. There are no noticable issues with our IPv6 connectivity, and RTT is also low towards the LE servers (both on IPv4 and IPv6), but curl still ends up using a lot of time on some of the queries over IPv6. Not sure if this is really an issue with LE's servers, but nontheless dehydrated should probably handle those errors more gracefully? I.e. by either a) retry the connection N times when it's `error 35`, or b) extend the timeout? (afaik the default timeout of curl is `0`, which is "forever", so not sure why `error 35` is even the issue). My ugly measurement setup; > `i=1;while true; do echo "`date`: Measurement #$i"; timelol="`{ time curl -s6 https://acme-staging.api.letsencrypt.org/acme/new-authz >/dev/null; } 2>&1 | grep real | perl -wple 's,real\s+,,g'`"; seconds=`echo $timelol|cut -d'.' -f1|perl -wple 's,0m,,'` ; if [ $seconds -gt 5 ]; then echo "`date`: Long measurement (#$i): $timelol"; fi; let i="i+1"; sleep 1; done` Did about 600 measurements, and ~60 of them had 5+ seconds. Most of them well below 30 seconds, and all of them below 60 seconds. Any takers?
adam closed this issue 2025-12-29 00:26:09 +01:00
adam commented 2025-12-29 00:26:10 +01:00
Author
Owner
Copy Link

@joachimtingvold commented on GitHub (Oct 13, 2016):

Results from the measurement;

Thu Oct 13 18:09:12 UTC 2016: Long measurement (#21): 0m6.205s
Thu Oct 13 18:10:48 UTC 2016: Long measurement (#52): 0m8.981s
Thu Oct 13 18:12:03 UTC 2016: Long measurement (#67): 0m36.409s
Thu Oct 13 18:13:03 UTC 2016: Long measurement (#86): 0m12.810s
Thu Oct 13 18:13:10 UTC 2016: Long measurement (#87): 0m6.192s
Thu Oct 13 18:13:36 UTC 2016: Long measurement (#90): 0m16.551s
Thu Oct 13 18:14:25 UTC 2016: Long measurement (#103): 0m9.804s
Thu Oct 13 18:15:06 UTC 2016: Long measurement (#114): 0m8.070s
Thu Oct 13 18:16:00 UTC 2016: Long measurement (#130): 0m8.104s
Thu Oct 13 18:16:46 UTC 2016: Long measurement (#143): 0m7.516s
Thu Oct 13 18:17:09 UTC 2016: Long measurement (#146): 0m15.988s
Thu Oct 13 18:17:34 UTC 2016: Long measurement (#149): 0m16.204s
Thu Oct 13 18:17:48 UTC 2016: Long measurement (#152): 0m8.387s
Thu Oct 13 18:18:26 UTC 2016: Long measurement (#153): 0m36.921s
Thu Oct 13 18:19:10 UTC 2016: Long measurement (#160): 0m31.603s
Thu Oct 13 18:20:12 UTC 2016: Long measurement (#178): 0m6.333s
Thu Oct 13 18:20:54 UTC 2016: Long measurement (#189): 0m8.390s
Thu Oct 13 18:21:13 UTC 2016: Long measurement (#193): 0m10.231s
Thu Oct 13 18:22:30 UTC 2016: Long measurement (#214): 0m16.182s
Thu Oct 13 18:22:45 UTC 2016: Long measurement (#217): 0m9.573s
Thu Oct 13 18:24:09 UTC 2016: Long measurement (#234): 0m31.919s
Thu Oct 13 18:25:02 UTC 2016: Long measurement (#251): 0m8.945s
Thu Oct 13 18:25:22 UTC 2016: Long measurement (#256): 0m8.541s
Thu Oct 13 18:26:53 UTC 2016: Long measurement (#276): 0m32.204s
Thu Oct 13 18:27:32 UTC 2016: Long measurement (#278): 0m34.973s
Thu Oct 13 18:28:03 UTC 2016: Long measurement (#287): 0m8.449s
Thu Oct 13 18:28:46 UTC 2016: Long measurement (#295): 0m16.320s
Thu Oct 13 18:30:08 UTC 2016: Long measurement (#311): 0m40.534s
Thu Oct 13 18:30:55 UTC 2016: Long measurement (#321): 0m16.758s
Thu Oct 13 18:31:35 UTC 2016: Long measurement (#331): 0m9.212s
Thu Oct 13 18:33:24 UTC 2016: Long measurement (#359): 0m16.584s
Thu Oct 13 18:34:06 UTC 2016: Long measurement (#366): 0m23.815s
Thu Oct 13 18:34:39 UTC 2016: Long measurement (#374): 0m11.867s
Thu Oct 13 18:34:52 UTC 2016: Long measurement (#377): 0m8.927s
Thu Oct 13 18:35:46 UTC 2016: Long measurement (#386): 0m32.073s
Thu Oct 13 18:36:31 UTC 2016: Long measurement (#392): 0m31.399s
Thu Oct 13 18:37:37 UTC 2016: Long measurement (#403): 0m35.073s
Thu Oct 13 18:37:57 UTC 2016: Long measurement (#407): 0m8.324s
Thu Oct 13 18:38:41 UTC 2016: Long measurement (#419): 0m8.283s
Thu Oct 13 18:39:31 UTC 2016: Long measurement (#435): 0m6.066s
Thu Oct 13 18:40:29 UTC 2016: Long measurement (#446): 0m23.713s
Thu Oct 13 18:40:59 UTC 2016: Long measurement (#451): 0m18.495s
Thu Oct 13 18:41:23 UTC 2016: Long measurement (#456): 0m8.452s
Thu Oct 13 18:42:21 UTC 2016: Long measurement (#464): 0m32.772s
Thu Oct 13 18:43:13 UTC 2016: Long measurement (#479): 0m8.431s
Thu Oct 13 18:43:44 UTC 2016: Long measurement (#484): 0m17.562s
Thu Oct 13 18:44:18 UTC 2016: Long measurement (#492): 0m9.841s
Thu Oct 13 18:44:25 UTC 2016: Long measurement (#493): 0m6.437s
Thu Oct 13 18:44:48 UTC 2016: Long measurement (#498): 0m12.118s
Thu Oct 13 18:45:12 UTC 2016: Long measurement (#504): 0m8.279s
Thu Oct 13 18:45:47 UTC 2016: Long measurement (#512): 0m8.117s
Thu Oct 13 18:46:29 UTC 2016: Long measurement (#516): 0m31.404s
Thu Oct 13 18:46:52 UTC 2016: Long measurement (#523): 0m6.006s
Thu Oct 13 18:47:16 UTC 2016: Long measurement (#530): 0m8.636s
Thu Oct 13 18:48:36 UTC 2016: Long measurement (#550): 0m17.499s
Thu Oct 13 18:48:53 UTC 2016: Long measurement (#552): 0m10.422s
Thu Oct 13 18:49:12 UTC 2016: Long measurement (#554): 0m15.935s
Thu Oct 13 18:49:47 UTC 2016: Long measurement (#556): 0m31.504s
Thu Oct 13 18:50:18 UTC 2016: Long measurement (#561): 0m10.033s
Thu Oct 13 18:50:57 UTC 2016: Long measurement (#564): 0m32.793s
Thu Oct 13 18:52:32 UTC 2016: Long measurement (#590): 0m24.894s
Thu Oct 13 18:52:53 UTC 2016: Long measurement (#592): 0m17.614s
Thu Oct 13 18:53:58 UTC 2016: Long measurement (#612): 0m9.991s
Thu Oct 13 18:54:45 UTC 2016: Long measurement (#624): 0m8.508s

mtr over IPv4;

jocke@kek:~$ mtr -n4 --report acme-staging.api.letsencrypt.org
Start: Thu Oct 13 19:02:09 2016
HOST: kek                         Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- <snip>                     0.0%    10    1.1   2.0   0.8   4.4   1.1
  2.|-- <snip>                     0.0%    10    0.4   0.5   0.4   0.9   0.0
  3.|-- 82.134.66.197              0.0%    10    1.2   1.3   1.1   1.8   0.0
  4.|-- 193.28.236.254             0.0%    10    7.6   7.5   7.3   7.6   0.0
  5.|-- 193.28.236.253             0.0%    10    7.6   7.7   7.5   8.7   0.3
  6.|-- 62.140.27.29               0.0%    10    7.7   7.6   7.5   7.8   0.0
  7.|-- 4.69.206.110              90.0%    10   14.8  14.8  14.8  14.8   0.0
  8.|-- 4.69.206.110              90.0%    10   14.7  14.7  14.7  14.7   0.0
  9.|-- 4.68.63.186                0.0%    10   14.5  14.5  14.4  14.7   0.0
 10.|-- 195.22.214.167             0.0%    10   37.0  36.9  36.8  37.4   0.0
 11.|-- 195.22.214.237             0.0%    10   36.8  36.9  36.7  37.2   0.0
 12.|-- 195.13.60.178              0.0%    10   46.0  46.2  45.8  46.4   0.0
 13.|-- 193.34.48.162             10.0%    10   51.2  51.4  50.0  53.4   0.7
 14.|-- 193.34.48.146              0.0%    10   51.5  52.0  51.0  55.8   1.3
 15.|-- 104.87.208.66             10.0%    10   50.8  51.3  50.8  52.3   0.0

mtr over IPv6;

jocke@kek:~$ mtr -n6 --report acme-staging.api.letsencrypt.org
Start: Thu Oct 13 19:02:09 2016
HOST: kek                         Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- <snip>                     0.0%    10    1.5   3.4   1.0  15.5   4.2
  2.|-- <snip>                     0.0%    10    0.5   0.5   0.4   0.7   0.0
  3.|-- 2a00:14d8:1001:734::1      0.0%    10    1.3   1.4   1.3   1.5   0.0
  4.|-- 2001:67c:324:2::2          0.0%    10    7.8   7.7   7.5   7.9   0.0
  5.|-- 2001:67c:324:2::1          0.0%    10    8.1   8.1   7.6   9.1   0.3
  6.|-- 2001:1900:5:2:2::3ea5      0.0%    10    7.7   7.7   7.5   7.9   0.0
  7.|-- 2001:1900:2::3:5f          0.0%    10   29.0  28.9  28.8  29.1   0.0
  8.|-- 2001:1900:4:3::266         0.0%    10   29.0  29.6  29.0  34.3   1.6
  9.|-- 2a01:3e0:ff40:200::21      0.0%    10   36.4  36.6  36.4  36.7   0.0
 10.|-- 2a01:3e0:ff40:200::16     30.0%    10   35.2  34.9  34.7  35.2   0.0
 11.|-- 2a02:b0:ffff:ffff:ffff:ff 10.0%    10   64.8  45.5  42.8  64.8   7.2
 12.|-- 2a02:b0:ffff:ffff:ffff:ff 20.0%    10   42.8  42.8  42.6  43.2   0.0
 13.|-- 2a02:26f0:d5:295::3d5     20.0%    10   42.8  42.9  42.7  43.3   0.0
@joachimtingvold commented on GitHub (Oct 13, 2016): Results from the measurement; ``` Thu Oct 13 18:09:12 UTC 2016: Long measurement (#21): 0m6.205s Thu Oct 13 18:10:48 UTC 2016: Long measurement (#52): 0m8.981s Thu Oct 13 18:12:03 UTC 2016: Long measurement (#67): 0m36.409s Thu Oct 13 18:13:03 UTC 2016: Long measurement (#86): 0m12.810s Thu Oct 13 18:13:10 UTC 2016: Long measurement (#87): 0m6.192s Thu Oct 13 18:13:36 UTC 2016: Long measurement (#90): 0m16.551s Thu Oct 13 18:14:25 UTC 2016: Long measurement (#103): 0m9.804s Thu Oct 13 18:15:06 UTC 2016: Long measurement (#114): 0m8.070s Thu Oct 13 18:16:00 UTC 2016: Long measurement (#130): 0m8.104s Thu Oct 13 18:16:46 UTC 2016: Long measurement (#143): 0m7.516s Thu Oct 13 18:17:09 UTC 2016: Long measurement (#146): 0m15.988s Thu Oct 13 18:17:34 UTC 2016: Long measurement (#149): 0m16.204s Thu Oct 13 18:17:48 UTC 2016: Long measurement (#152): 0m8.387s Thu Oct 13 18:18:26 UTC 2016: Long measurement (#153): 0m36.921s Thu Oct 13 18:19:10 UTC 2016: Long measurement (#160): 0m31.603s Thu Oct 13 18:20:12 UTC 2016: Long measurement (#178): 0m6.333s Thu Oct 13 18:20:54 UTC 2016: Long measurement (#189): 0m8.390s Thu Oct 13 18:21:13 UTC 2016: Long measurement (#193): 0m10.231s Thu Oct 13 18:22:30 UTC 2016: Long measurement (#214): 0m16.182s Thu Oct 13 18:22:45 UTC 2016: Long measurement (#217): 0m9.573s Thu Oct 13 18:24:09 UTC 2016: Long measurement (#234): 0m31.919s Thu Oct 13 18:25:02 UTC 2016: Long measurement (#251): 0m8.945s Thu Oct 13 18:25:22 UTC 2016: Long measurement (#256): 0m8.541s Thu Oct 13 18:26:53 UTC 2016: Long measurement (#276): 0m32.204s Thu Oct 13 18:27:32 UTC 2016: Long measurement (#278): 0m34.973s Thu Oct 13 18:28:03 UTC 2016: Long measurement (#287): 0m8.449s Thu Oct 13 18:28:46 UTC 2016: Long measurement (#295): 0m16.320s Thu Oct 13 18:30:08 UTC 2016: Long measurement (#311): 0m40.534s Thu Oct 13 18:30:55 UTC 2016: Long measurement (#321): 0m16.758s Thu Oct 13 18:31:35 UTC 2016: Long measurement (#331): 0m9.212s Thu Oct 13 18:33:24 UTC 2016: Long measurement (#359): 0m16.584s Thu Oct 13 18:34:06 UTC 2016: Long measurement (#366): 0m23.815s Thu Oct 13 18:34:39 UTC 2016: Long measurement (#374): 0m11.867s Thu Oct 13 18:34:52 UTC 2016: Long measurement (#377): 0m8.927s Thu Oct 13 18:35:46 UTC 2016: Long measurement (#386): 0m32.073s Thu Oct 13 18:36:31 UTC 2016: Long measurement (#392): 0m31.399s Thu Oct 13 18:37:37 UTC 2016: Long measurement (#403): 0m35.073s Thu Oct 13 18:37:57 UTC 2016: Long measurement (#407): 0m8.324s Thu Oct 13 18:38:41 UTC 2016: Long measurement (#419): 0m8.283s Thu Oct 13 18:39:31 UTC 2016: Long measurement (#435): 0m6.066s Thu Oct 13 18:40:29 UTC 2016: Long measurement (#446): 0m23.713s Thu Oct 13 18:40:59 UTC 2016: Long measurement (#451): 0m18.495s Thu Oct 13 18:41:23 UTC 2016: Long measurement (#456): 0m8.452s Thu Oct 13 18:42:21 UTC 2016: Long measurement (#464): 0m32.772s Thu Oct 13 18:43:13 UTC 2016: Long measurement (#479): 0m8.431s Thu Oct 13 18:43:44 UTC 2016: Long measurement (#484): 0m17.562s Thu Oct 13 18:44:18 UTC 2016: Long measurement (#492): 0m9.841s Thu Oct 13 18:44:25 UTC 2016: Long measurement (#493): 0m6.437s Thu Oct 13 18:44:48 UTC 2016: Long measurement (#498): 0m12.118s Thu Oct 13 18:45:12 UTC 2016: Long measurement (#504): 0m8.279s Thu Oct 13 18:45:47 UTC 2016: Long measurement (#512): 0m8.117s Thu Oct 13 18:46:29 UTC 2016: Long measurement (#516): 0m31.404s Thu Oct 13 18:46:52 UTC 2016: Long measurement (#523): 0m6.006s Thu Oct 13 18:47:16 UTC 2016: Long measurement (#530): 0m8.636s Thu Oct 13 18:48:36 UTC 2016: Long measurement (#550): 0m17.499s Thu Oct 13 18:48:53 UTC 2016: Long measurement (#552): 0m10.422s Thu Oct 13 18:49:12 UTC 2016: Long measurement (#554): 0m15.935s Thu Oct 13 18:49:47 UTC 2016: Long measurement (#556): 0m31.504s Thu Oct 13 18:50:18 UTC 2016: Long measurement (#561): 0m10.033s Thu Oct 13 18:50:57 UTC 2016: Long measurement (#564): 0m32.793s Thu Oct 13 18:52:32 UTC 2016: Long measurement (#590): 0m24.894s Thu Oct 13 18:52:53 UTC 2016: Long measurement (#592): 0m17.614s Thu Oct 13 18:53:58 UTC 2016: Long measurement (#612): 0m9.991s Thu Oct 13 18:54:45 UTC 2016: Long measurement (#624): 0m8.508s ``` mtr over IPv4; ``` jocke@kek:~$ mtr -n4 --report acme-staging.api.letsencrypt.org Start: Thu Oct 13 19:02:09 2016 HOST: kek Loss% Snt Last Avg Best Wrst StDev 1.|-- <snip> 0.0% 10 1.1 2.0 0.8 4.4 1.1 2.|-- <snip> 0.0% 10 0.4 0.5 0.4 0.9 0.0 3.|-- 82.134.66.197 0.0% 10 1.2 1.3 1.1 1.8 0.0 4.|-- 193.28.236.254 0.0% 10 7.6 7.5 7.3 7.6 0.0 5.|-- 193.28.236.253 0.0% 10 7.6 7.7 7.5 8.7 0.3 6.|-- 62.140.27.29 0.0% 10 7.7 7.6 7.5 7.8 0.0 7.|-- 4.69.206.110 90.0% 10 14.8 14.8 14.8 14.8 0.0 8.|-- 4.69.206.110 90.0% 10 14.7 14.7 14.7 14.7 0.0 9.|-- 4.68.63.186 0.0% 10 14.5 14.5 14.4 14.7 0.0 10.|-- 195.22.214.167 0.0% 10 37.0 36.9 36.8 37.4 0.0 11.|-- 195.22.214.237 0.0% 10 36.8 36.9 36.7 37.2 0.0 12.|-- 195.13.60.178 0.0% 10 46.0 46.2 45.8 46.4 0.0 13.|-- 193.34.48.162 10.0% 10 51.2 51.4 50.0 53.4 0.7 14.|-- 193.34.48.146 0.0% 10 51.5 52.0 51.0 55.8 1.3 15.|-- 104.87.208.66 10.0% 10 50.8 51.3 50.8 52.3 0.0 ``` mtr over IPv6; ``` jocke@kek:~$ mtr -n6 --report acme-staging.api.letsencrypt.org Start: Thu Oct 13 19:02:09 2016 HOST: kek Loss% Snt Last Avg Best Wrst StDev 1.|-- <snip> 0.0% 10 1.5 3.4 1.0 15.5 4.2 2.|-- <snip> 0.0% 10 0.5 0.5 0.4 0.7 0.0 3.|-- 2a00:14d8:1001:734::1 0.0% 10 1.3 1.4 1.3 1.5 0.0 4.|-- 2001:67c:324:2::2 0.0% 10 7.8 7.7 7.5 7.9 0.0 5.|-- 2001:67c:324:2::1 0.0% 10 8.1 8.1 7.6 9.1 0.3 6.|-- 2001:1900:5:2:2::3ea5 0.0% 10 7.7 7.7 7.5 7.9 0.0 7.|-- 2001:1900:2::3:5f 0.0% 10 29.0 28.9 28.8 29.1 0.0 8.|-- 2001:1900:4:3::266 0.0% 10 29.0 29.6 29.0 34.3 1.6 9.|-- 2a01:3e0:ff40:200::21 0.0% 10 36.4 36.6 36.4 36.7 0.0 10.|-- 2a01:3e0:ff40:200::16 30.0% 10 35.2 34.9 34.7 35.2 0.0 11.|-- 2a02:b0:ffff:ffff:ffff:ff 10.0% 10 64.8 45.5 42.8 64.8 7.2 12.|-- 2a02:b0:ffff:ffff:ffff:ff 20.0% 10 42.8 42.8 42.6 43.2 0.0 13.|-- 2a02:26f0:d5:295::3d5 20.0% 10 42.8 42.9 42.7 43.3 0.0 ```
adam commented 2025-12-29 00:26:13 +01:00
Author
Owner
Copy Link

@joachimtingvold commented on GitHub (Oct 18, 2016):

So, the high request-time is gone (for now), but the point of this issue still remains (i.e. dehydrated should handle timeouts better).

@joachimtingvold commented on GitHub (Oct 18, 2016): So, the high request-time is gone (for now), but the point of this issue still remains (i.e. dehydrated should handle timeouts better).
adam commented 2025-12-29 00:26:14 +01:00
Author
Owner
Copy Link

@lukas2511 commented on GitHub (Jul 10, 2017):

Error handling is kinda hard in itself, and (at least for me) even harder in bash. So unless somebody starts paying me for work on this script I don't really want to implement retries and stuff, sorry.

But: I just implemented a cache for certificate chains which at least should lower the amount of http requests and with that lower the chance of one of them failing...

@lukas2511 commented on GitHub (Jul 10, 2017): Error handling is kinda hard in itself, and (at least for me) even harder in bash. So unless somebody starts paying me for work on this script I don't really want to implement retries and stuff, sorry. But: I just implemented a cache for certificate chains which at least should lower the amount of http requests and with that lower the chance of one of them failing...
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Complicated
bug
enhancement
help wanted
pull-request
Mirrored from GitHub Pull Request
 suggestions wanted
testing
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/dehydrated#156
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?