Connection aborted. OSError 107

Hi @srulikuk

searching that error -> problems with your harddisk or mount points.

(Easiest) Solution: Reboot your server.

Its a fresh installation only for certbot, still using nginx
I started having problems renewing on my old ubuntu 14.04 installations in the last few weeks
(~# curl -4 https://acme-v02.api.letsencrypt.org
curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to acme-v02.api.letsencrypt.org:443)
So i made this fresh install for the sole purpose of creating and renewing the certs.

On the same disk(s) as before?

No, its a new VM ubuntu 18.04

But is it in the same hyper-visor host?
[using the same disk(s)]

Are they local or remotely mounted disks?

Yes same host, are you saying I should try to reboot the host? (that’s really a last case for me)

I wouldn’t got there just yet…
Can you check the drive subsystem?
Any alarms/failures/etc. related to disk access?
Can you inspect them visually?
[a lot of times you can see rows of green blinking lights and the one red/yellow/orange light crying for help!]

Please use Google and read some of the results.

One of your mount points doesn’t work, so it’s not a problem of a program. Instead, it’s a problem of your hardware. Unmounting in a running system may be more critical then rebooting the system.

In a perfect world, he would be using a hot-swappable drive subsystem.
And only one drive is going bad in a raid5 system and it’s just pull one out and put a new one in.
But you may be right, I may be crazy.
[Billy Joel in my head now]

1 Like

I am using hot-swappable but the world still aint perfect :wink:
I don’t have physical access to the server at the moment but I used “hpacucli” to check the condition of the 8 drives and the array, all reported “OK”.
Cant see anything relevant in logs.
If its a mount point a reboot of the VM should have resolved it.
I will play google for a little longer and if no joy I will reboot the server later.

1 Like

Best of luck :slight_smile:
You should run some sort of disk benchmark tool to prove its condition.
[perhaps a driver was recently updated and BAM!]

I tested all the drives today (removed 1 by 1 and created some large files and allowed the raid to rebuild, all without issue.)
Rebooted now and issue remains.
what a shame that i broke this record ->
root@serv-0:~# uptime
20:30:34 up 1196 days, 20:26,

Form my google searches I did not find anywhere that’s its hardware / mount point related, all i found is its problem in the python code.

Any ideas please?

And we start again… :slight_smile:

Force the renewal challenge location to a less used and 100% stable path…?

Not sure what you mean

The “default” location for the challenge file is /your/document_root/.well-known/acme-challenge/
This can be overridden to any location via an nginx location statement.

With something like this in your port 80 vhost config:

 location /.well-known/acme-challenge/ {
  root /some/stable/path/; #<<<change that to your specific location
  try_files $uri =404;
 }#location

are you sure it requires /acme-challenge/ in the path? i never used that before, in any case I tried now with and without still have same error.

My main nginx config now has
location /.well-known/acme-challenge/ {
proxy_set_header X-Real-IP $remote_addr;
proxy_pass http://192.168.10.15 ;
}
The server I am running certbot on now has
location /.well-known/acme-challenge/ {
alias /var/www/html/.well-known/ ;
}
i put a text file in /.well-known/acme-challenge/ and its reachable from the web, no issue

I tried few other location including home dir and /usr/share/nginx/html/certbot/ same issue.

IMHO It is 100% a issue with the renewal script or something in default config.
~# certbot certolny --webroot -w /var/www/html/ -d www.example.com -d example.com -d example1.com -d example3.com -d example4.com -d example5.com -d example6.com -d example7.com -d www.example8.com -d example8.com


2: Renew & replace the cert (limit ~5 per 7 days)


Select the appropriate number [1-2] then [enter] (press ‘c’ to cancel): 2
Renewing an existing certificate

IMPORTANT NOTES:

  • Congratulations! Your certificate and chain have been saved at:
1 Like

Not sure about the “alias inside location” vs “root inside location”…
[that is for another day]

My point was to set the location (via alias or root) to ANOTHER place; one more likely to be highly available and less in use (that could be: /tmp for all I know - I don’t know your system).

This VM has zero use, i set it up purely to generate / renew certs, its not an availability issue.

its a clean ubuntu 18.04 server install all default configs only packages i installed are those required to run cerbot

is there a way to manually renew non-interactively?
[certbot certonly --webroot -w /var/www/html/ -d www.example.com -d example.com]
i will just create a cron job to run this