Silent Cron Mode


#1

I’m currently running the renew function every night via a cron job and it sends me a little email stating something like:

The following certs are not due for renewal yet:
/etc/letsencrypt/yada/yada.pem
No renewals were attempted.

I’m become inured to these emails. I just don’t see them any more, and if there were ever an error, I’d miss it entirely. Since missing an error could be catastrophic, I need to change…something.

Is there a suggested way to run the cron job so that it doesn’t email you every time it runs, but you still see errors?


#2

You could write a small bash script that parses the return code and output of letsencrypt-auto. Here’s one I’m using to log relevant events to syslog - it should be simple enough to swap one of the logger commands with some mail magic. (Note: It doesn’t use renew as that wasn’t yet supported at the time, but should work with renew as well.)

#!/bin/bash
OUT=$(/root/letsencrypt/letsencrypt-auto certonly -a webroot \
				--webroot-path /var/www/html -d example.com \
				--server https://acme-v01.api.letsencrypt.org/directory \
				--agree-tos --expand --keep-until-expiring)
if [ $? -eq 0 ]; then
	if grep -q "Congratulations!" <<<$OUT; then
		logger -t letsencrypt certificates renewed successfully
		service nginx reload
		if [ $? -eq 0 ]; then
			logger -t letsencrypt nginx reload successful
		else
			logger -t letsencrypt nginx reload failed
		fi
	else
		logger -t letsencrypt certificate not due for renewal
	fi
else
	logger -t letsencrypt error during renewal
fi

#3

I agree that would be a nice improvement. We’ve got an open issue for it in the client: https://github.com/letsencrypt/letsencrypt/issues/2512


#4

If all you’re looking for is to just “silent” your cron job, consider redirecting the output.

/path/to/letsencrypt renew 1>/var/log/letsencrypt/letsencrypt.renew.log 2>&1

If you would like to append to your log file, like:

/path/to/letsencrypt renew 1>>/var/log/letsencrypt/letsencrypt.renew.log 2>&1

(note the double ‘>>’ in the redirection) then you should consider creating an entry for logrotate (assuming you’ve got logrotate installed).

The advantage of appending is of course that you’ll be able to see multiple previous results of your renewal activities in the log. The inconvenience is that the log will grow and you’ll have to somewhat purge it, hence my advice to use logrotate to “rotate” the log files.

If you want to, you could also consider pushing any potential error messages into a different file, so as to notice that errors are produced. Like:

/path/to/letsencrypt renew 1>>/var/log/letsencrypt/letsencrypt.renew.log 2>>/var/log/letsencrypt/letsencrypt.renew-errors.log

and then create a second entry in your logrotate setup for the error file.


#5

Yeah, I should have mentioned I’m familiar with output redirection. Thanks for the details though.

I think where that falls short is that output redirection will just silence things completely, whereas what I want is a mode that tells me only non-routine information:

  • New certificate is all set.
  • New certificate failed.

I can’t think of anything else I’d want to know. I think my best bet might be to redirect standard out to /dev/null, and hope that receiving errors is sufficient, but I can’t be sure I won’t miss an important message that way, so…it’s not great.

The only other approach I can think of is to do roughly what @pfg is suggesting: Hunt for specific strings in the output. I think I’ll do this with super-specific email filters instead of a bash script like @pfg does, but damn…not ideal.


#6

Hunt for specific strings in the output.

Using a script, yes.

But potentially take the approach to throw away what you don’t wanna hear about and output everything else (everything unexpected) on STDOUT, thereby letting cron send it to you in the mail.


#7

I have an honest question - do you need to run the renew cron daily? I’ve got mine set to weekly, so there’s still at least three runs within that last month trying to renew.

Once I week I review my other weekly system output emails anyway, so I get to review the LE cronjob output at the same time. I don’t see a huge advantage of running it daily. I mean, you get more LE cron emails in a week than I get a month, for no obvious benefit!

Am I missing something? Is there a reason to run it daily? I don’t see the advantage. If my renew fails for whatever reason, I’m going to see the message and take action, with weeks of spare time left. And that doesn’t even take the reminder emails into account as a failsafe.

(But despite all that, it would be awesome to have a silent option available anyway, I just don’t see a huge pressing need.)


#8

It’s by design that most Unix core utilities exit silently [*] on success. Obviously, cron is designed around this standard practise as well.

I agree that a cron mode would be beneficial to the busy sysadmins who want to improve the signal-to-noise ratio of their inbox.

[*] No output to stdout, and returns 0.


#9

I think the daily run is due to fear mostly, if I’m honest with myself. I don’t want some weird timing thing to screw it up and I don’t want to spend time thinking through whether some weird month would have some weird confluence of days and weekends and who knows what.

Having written that though, I realize it’s just fear, and this change will help fix the problem, so I’ll do it.

Still, I’d love a silent mode.


#10

Fair enough. I’d really appreciate silent mode as well. I’d use it if it was available.


#11

@DarkSteve

I have an honest question - do you need to run the renew cron daily? I’ve got mine set to weekly, so there’s still at least three runs within that last month trying to renew.

In the "Getting Started’ document provided by the Let’s Encrypt organization it’s written that:

Once you’re happy with your script, you can run it with cron or systemd. We recommend running renewal scripts at least daily, at a random hour and minute. This gives the script many days to retry renewal in case of transient network failures or server outages.

See: https://letsencrypt.org/getting-started/

Having said that, it is of course totally up to you how often you want to attempt a renewal. What I want to advance is that Let’s Encrypt will not tell us we’re abusing the renewal procedures if we run it daily, or even multiple times per day.


#12

I saw that, but it doesn’t say why they recommend renewal should be run daily. It seems a bit silly, especially if the result is inconveniencing you.

Hence my question as to why.


#13

The idea is to allow the renewal to be attempted as soon as the renewal window is reached (by default, 30 days), or, if you have a lot of different certs on your machine, to allow each one’s renewal to be attempted as soon as its renewal window is reached. There’s no technical requirement to run daily or on any particular recurring schedule; it’s just a matter of safety and convenience because we thought many users would like all their renewals to be attempted promptly.


#14

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