Certbot-auto renew... doesn't

Help
1

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. https://crt.sh/?q=example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is:
ayrmesh.com

I ran this command:
./certbot-auto renew --no-bootstrap

It produced this output:
Creating virtual environment…
Error: Command ‘[’/opt/eff.org/certbot/venv/bin/python3’, ‘-Im’, ‘ensurepip’, ‘–upgrade’, ‘–default-pip’]’ returned non-zero exit status 1

My web server is (include version):
Apache/2.2.15 (Unix)

The operating system my web server runs on is (include version):
CentOS release 6.6 (Final)
Linux ip-50-63-186-208.ip.secureserver.net 2.6.18-028stab118.1 #1 SMP Thu Feb 12 16:43:22 MSK 2015 x86_64 x86_64 x86_64 GNU/Linux

My hosting provider, if applicable, is:
GoDaddy VPS

I can login to a root shell on my machine (yes or no, or I don’t know):
Yes

I’m using a control panel to manage my site (no, or provide the name and version of the control panel):
No

The odd thing is that I have another server, ayrmesh.net, on another VPS (Turnkey Internet), running Centos6.9 and Python 3.4.5, and it renews just fine. The two environments are as close as I can get to identical.

NOTE: I get the same result if I leave off --no-bootstrap, but it takes a lot longer to fail…

URGENT NOTE: the certificate expires today, and this is a production server. I figured I’d figure this out by now…

2

Hi @bmoffitt,

Maybe try with --no-self-upgrade for now? If it fails, maybe try deleting /opt/eff.org and then re-running ./certbot-auto --renew.

We always recommend running your renew command from a cron job so that Certbot can try to renew starting 30 days prior to expiry.

3

Hi, @schoen!

Thank you for the suggestions - I’m grateful, but, unfortunately, neither worked.

I’m far from a Python expert - a complete neophyte, However, when I type the offending command on the server that’s not working, I get:

python3 -m ensurepip --upgrade --default-pip

Ignoring indexes: https://pypi.python.org/simple
Requirement already up-to-date: setuptools in /usr/lib/python3.4/site-packages
Requirement already up-to-date: pip in /usr/lib/python3.4/site-packages
Traceback (most recent call last):
File “/usr/lib64/python3.4/runpy.py”, line 170, in _run_module_as_main
“main”, mod_spec)
File “/usr/lib64/python3.4/runpy.py”, line 85, in _run_code
exec(code, run_globals)
File “/usr/lib64/python3.4/ensurepip/main.py”, line 4, in
ensurepip._main()
File “/usr/lib64/python3.4/ensurepip/init.py”, line 209, in _main
default_pip=args.default_pip,
File “/usr/lib64/python3.4/ensurepip/init.py”, line 116, in bootstrap
_run_pip(args + [p[0] for p in _PROJECTS], additional_paths)
File “/usr/lib64/python3.4/tempfile.py”, line 709, in exit
self.cleanup()
File “/usr/lib64/python3.4/tempfile.py”, line 713, in cleanup
_shutil.rmtree(self.name)
File “/usr/lib64/python3.4/shutil.py”, line 468, in rmtree
_rmtree_safe_fd(fd, path, onerror)
File “/usr/lib64/python3.4/shutil.py”, line 390, in _rmtree_safe_fd
onerror(os.listdir, path, sys.exc_info())
File “/usr/lib64/python3.4/shutil.py”, line 387, in _rmtree_safe_fd
names = os.listdir(topfd)
OSError: [Errno 22] Invalid argument: ‘/tmp/tmp5iwfrv49’

which makes me think I have screwed up some Python-related setting somewhere.

On the other server, I get:

]# python3 -m ensurepip --upgrade --default-pip
Ignoring indexes: https://pypi.python.org/simple
Collecting setuptools
Collecting pip
Installing collected packages: setuptools, pip
Successfully installed pip-8.1.1 setuptools-20.10.1

But I don’t know where to even look for config differences. All the package versions appear to be the same at first glance in yum.

4

Oh, and for your amusement (you deserve that, at least), I DO have it in my crontab. And it has been failing consistently for the last 30 days. And I have been largely ignoring it until last week.

I figured it was going to be something simple that would take me 10 minutes to figure out. I messed around with it for several hours on Friday, did a bunch of useless Googling over the weekend, and realized this morning that I am deep poopy.

So I’m not a perfect idiot. Indeed, I’m a very flawed idiot! :joy::rofl:

However, I must face the fact that I have a server that’s about to become unreachable… :confused::astonished::confounded:

Thanks!

5

Hi @bmoffitt,

Sorry, I don’t know how to fix your python issue but if you are in a hurry (your cert expires in 2-3 hours) you could use other client like https://github.com/Neilpang/acme.sh which is a shell script with almost no dependencies or use an online service like zerossl https://zerossl.com/free-ssl/#crt to issue your cert and once done and installed in your server, you can try to figure out what’s wrong with your setup.

Good luck,
sahsanu

3 Likes
6

@bmw @joohoi, do you know what’s going wrong here?

7

This looks like a very broken virtualenv. The best advice was probably always handed out to sort this issue, and it was to delete the old virtualenv. Just as a note for @bmoffitt : this operation does not delete or modify your renewal configuration nor the active certificates in any way. It will just recreate the Python virtual environment used by Certbot.

Oh, and please make sure you have disk space available in /opt

1 Like
8

@sahsanu-

That was a really good piece of advice - I followed it, installed the certs, and now have some time to figure the rest of this stuff out. I’ll get auto-renew working with acme.sh or certbot-auto…

Muchas gracias!!!

-Bill

1 Like
9

@joohoi-

I agree; the only problem is that the venv is just linked to my REAL environment… so I think I have fouled up my actual Python instance. This idea is validated by the fact that just running

> # python3 -m ensurepip --upgrade --default-pip

At the command line fails (and runs just fine on the other server that’s using certbot-auto, Centos6, and Python 3.4.5).

One thing I saw suggested that the permissions might be incorrect on /tmp, but I checked that and the files are rw-r–r--, so root should be able to write.

It’s a bit of a mystery, and I’m not convinced it’s really a Certbot-auto problem at all. Debugging my Python installation, however, is… difficult.

Thanks,

-Bill

10

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.