Yeah for d1g I believe it's a faulty cron line, which then fails to
restart nginx properly. The installed line has the following command line:
`test -x /usr/bin/certbot && certbot -q renew || certbot -q renew
--pre-hook="service nginx stop" --post-hook "service nginx start"`

I don't really know where the cron line came from (it's in /etc/cron.d),
but I suspect the "||" is actually installation advice, telling the
person to chose the one way or other for certbot invocation.

Due to the amount of useful scripting involved, I can't work out the
circumstance where "certbot -q renew" would fail; logically it should
fail when a renewal is required, and at that time the longer invocation
should kick in to perform the renewal (and restart the server). By my
guess, though, it doesn't fail and rather just renews the cert, and then
leaves nginx without restart. Alternatively, that "-q" is misplaced in
the second invocation phrase (if it means "check but don't renew")

Anyone who knows something should chirp in.

Ralph.

Alberto Zuin wrote on 16/07/17 03:55:
> By default It is 30 days and you can double check if the certificate was renewed by the certbot with openssl:
>
> openssl x509 -in /etc/letsencrypt/live/devuan.org/fullchain.crt -text -noout
>
> (Amend the path accordingly)
>
> If the certificate was renewed, at 99% it's nginx which must be restarted (a reload is not enough).
>
> I hope this helps,
> Alberto
>
> Original Message
> From: golinux@???
> Sent: 15 July 2017 18:27
> To: devuan-dev@???
> Reply to: devuan-dev@???
> Subject: Re: [devuan-dev] devuan.org cert
>
> On 2017-07-15 11:28, Evilham wrote:
>> Am 15/07/2017 um 18:25 schrieb KatolaZ:
>>> git.devuan.org is under certbot. I guess all of them are under
>>> certbot. I am not sure as of whether the web server gets restarted
>>> correctly after the cert is updated on each of them (it does on
>>> git.devuan.org, bugs.devuan.org, popcon.devuan.org).
>> Do you happen to know _when_ it tries to update the cert? I added a
>> 15day check, but if cerbot tries to update 10 days before expiry, that
>> check is not telling us if certbot did its job.
>>
>> Basically I'd have to adapt my external cert checks, so that they
>> trigger *after* certbot was supposed to renew them. That way we should
>> only get an email about the certificates if it was not the case.
>
> -----------------------------------
>
> FYI, from D1G irc logs:
>
> 2017-07-05 08:58:49 rrq: re cert: the standard set up runs "certbot
> renew" every 12 hours (midday + midnight), which
> 2017-07-05 08:59:14 rrq: supposedly renews the cert if near expiry.
> 2017-07-05 08:59:26 rrq: I'm trying to find out what "near" means.
> 2017-07-05 08:59:43 rrq: logically it should be >12h
> 2017-07-05 09:00:46 rrq: but there's been some serious python vomit:
> 7425 lines to do its thing :-(
> 2017-07-05 09:09:30 rrq: hmm default renewal supposedly is 30 days (or
> less) before expiry
> 2017-07-05 09:17:57 golinux: So what went wrong? Any tracks in the logs?
> You know that the Devuan certs fail regularly
> 2017-07-05 09:24:13 rrq: afaics nothing in the logs
> 2017-07-05 09:35:35 rrq: I changed the cron line to make the certbot
> invocation log to /tmp/certbot.log
> 2017-07-05 09:36:12 rrq: the cert is 3 months, so that log will be
> interesting in about 2 months
>
> I think part of the problem is that nginx isn't getting restarted.
> We'll be watching our certbot closely till the next renewal.
>
> golinux
>
> _______________________________________________
> devuan-dev internal mailing list
> devuan-dev@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/devuan-dev
> _______________________________________________
> devuan-dev internal mailing list
> devuan-dev@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/devuan-dev
>