I'm using Let's Encrypt to generate SSL certificates automatically every 60-days using a simple shell script.

After the script has reloaded these it tries to reload my services using the commands I would type myself into a shell, i.e- service postfix reload and service dovecot reload.

However, while the first of these works just fine, the service dovecot reload does not work, complaining of an unrecognised service.

The script is being run as root as a cron-job, so I would expect it to recognise all the same services as when I'm logged in as root myself, yet for some reason dovecot is not recognised, but others are without issue, meaning I have to manually reload dovecot before the old certificates expire, kind of limiting the benefit of my script!

What is different about dovecot that would cause it to be unrecognised by my script, but be recognised without issue when I log in as root myself?

Output of lsb_release -a:

 No LSB modules are available.
 Distributor ID:    Ubuntu
 Description:   Ubuntu 14.04.5 LTS
 Release:   14.04
 Codename:  trusty

Output of ps aux | grep dovecot:

root       860  0.0  0.1  22144  1052 ?        Ss   May09   1:33 /usr/sbin/dovecot -F -c /etc/dovecot/dovecot.conf
dovecot   1466  0.0  0.0   9288   572 ?        S    May09   0:11 dovecot/anvil
vmail    22753  0.0  0.4  23904  4116 ?        S    16:58   0:00 dovecot/imap
vmail    22754  0.0  0.5  25408  5764 ?        S    16:58   0:00 dovecot/imap
dovenull 24108  0.0  0.3  19188  3812 ?        S    Sep26   0:10 dovecot/imap-login
root     24109  0.0  0.1   9416  1472 ?        S    Sep26   0:00 dovecot/log
root     24111  0.0  0.2  23772  2660 ?        S    Sep26   0:01 dovecot/config
vmail    30218  0.0  0.3  23244  3676 ?        S    22:40   0:00 dovecot/imap
vmail    30219  0.0  0.3  23252  3540 ?        S    22:40   0:00 dovecot/imap
root     30293  0.0  0.4  27924  4416 ?        S    22:44   0:00 dovecot/lmtp
dovecot  30294  0.0  0.4  39632  4756 ?        S    22:44   0:00 dovecot/auth
root     30295  0.1  0.4  39728  4900 ?        S    22:44   0:00 dovecot/auth -w
  • 2
    @mongrel "Recognise" is perfectly fine English, please refrain from changing such spelling. – Anthon Aug 12 '16 at 10:01
  • Could you paste your cron file and, if it invokes another shell script (which contains service dovecot reload), that script too? Could you also paste your dovecot's service file with its path (it's probably located at /etc/systemd/system/dovecot.service or something like that)? Probably we can deduce something from that. I suspect that it's, as usual with cronjobs, a problem of crond environment. – Pavel Gurkov Sep 27 '16 at 16:58
  • 1
    Can you let us know what the distribution and version number is? If lsb_release -a produces any meaningful output - add it to the question. At the moment I doubt it is environment related issue since service should run your command under a deterministic environment. – chutz Sep 27 '16 at 17:37
  • With dovecot running, could you also post $ ps aux | grep dovecot – Stephan Sep 28 '16 at 20:27
  • 1
    What's the exact error message please? – roaima Sep 28 '16 at 23:15

It seems that your problem is because cron scripts run with a different PATH value by default. For example, on Ubuntu as root you have /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin in your PATH by default. But your cron script running as root has a more limited PATH value: /usr/bin:/bin.

I recommend you to to set the PATH environment variable at the top of your cron scripts:


In this particular case the problem is that the service script uses /sbin/initctl (Upstart), which is not in the PATH used by cron. If that command fails, it then tries to use the traditional /etc/init.d/${SERVICE} script. But not all the services include that old script and that's why your script works with some services but not with others.

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.