I have two units, nginx.service and certbot.service, provided by their respective Debian packages:


Description=A high performance web server and a reverse proxy server

ExecStartPre=/usr/sbin/nginx -t -q -g 'daemon on; master_process on;'
ExecStart=/usr/sbin/nginx -g 'daemon on; master_process on;'
ExecReload=/usr/sbin/nginx -g 'daemon on; master_process on;' -s reload
ExecStop=-/sbin/start-stop-daemon --quiet --stop --retry QUIT/5 --pidfile /run/nginx.pid



ExecStart=/usr/bin/certbot -q renew

And a timer, certbot.timer (also provided by the certbot deb package):

Description=Run certbot twice daily

OnCalendar=*-*-* 00,12:00:00


These all work fine.

The problem, is that I need to reload nginx when the timer fires for nginx to see the new certificates (systemctl reload nginx).

I know I can do systemctl edit certbot.service, and add:

ExecStartPost=/bin/systemctl reload nginx

In fact, this is what I've done, but it's a kludge. Is there any way to achieve this with native systemd dependencies? The tricky thing is triggering reload only and not a full blown restart.

  • Have you ever figured out a systemd solution to your problem? I have a very similar problem that I'd like to solve: unix.stackexchange.com/q/717642/399674
    – Fonic
    Sep 17 at 19:49
  • Hi @Fonic, in the end I made do with the kludge, but I am glad to see you got a potential solution to your question. Sep 20 at 13:48

1 Answer 1


You can just add a deploy hook (not a post hook; you only need to do this if a cert is deployed) directly to the certbot configuration for your domain, in /etc/letsencrypt/renewal/example.com.conf.

In the [renewal] section, add a line like:

deploy_hook = systemctl reload nginx

That is all. You don't need to do strange things to the systemd units.

  • 1
    Thanks for this, it is a good answer to my original problem, but not the actual question! So I'll upvote for usefulness, but I can't mark it as the accepted answer. I think the service manager is the right place to do this sort of thing. Apr 17, 2019 at 19:40
  • @AlexForbes Systemd is absolutely the wrong place to do this sort of thing. You may need different deploy hooks for each DNS name, for instance, (e.g. getting certs for both nginx and postfix, each with different names) and that gets completely unmaintainable if you try to cram it into a systemd unit or override. Apr 18, 2019 at 2:34
  • 3
    We're getting into a philosophical debate here, but by "sort of thing", I mean coupling services together. Systemd is absolutely the right place to declare service dependencies. It's one of the main reasons it exists. I think it's actually an interesting debate but this comment field is too limited so I'm going to break down my thoughts on when to use generalist vs domain-specific solutions into a blog post when I have more time. I'll link it here, would be interested in your thoughts! Apr 18, 2019 at 11:19
  • 2

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.