5 ms·

crontab -e is the way to edit your cron. A similar command exists for editing the sudoers file which is visudo. This will ensure your configuration is a valid s

crontab -e is the way to edit your cron. A similar command exists for editing the sudoers file which is visudo. This will ensure your configuration is a valid syntax as well as do an atomic swap of the file. Otherwise adding a file or deleting a file in /etc/cron.d/ is the way to go for automatic(ansbile, puppet etc) and package installations.

krrrh 10y ago
I'm surprised that people would edit cron in any other way, crontab -e is one of the first commands most intro to Linux manuals teaches. However crontab -r has to be one of the most poorly thought out commands in UNIX. It removes the cron file and since r is only one character over from e on qwerty keyboards it's a painful and surprising typo.
- efiala 10y ago
  what if you are managing the crons externally, eg puppet, crontab -e is not always option
  - Godel_unicode 10y ago
    1. If you don't have a test process for changes made with puppet, this is hardly a problem with cron. 2. Puppet handled that parsing for you and will throw errors if your syntax is wrong
  - hibbelig 10y ago
    Use /bin/cat as editor. That should work nicely from Puppet.
  - _ao789 10y ago
    I can't tell you the amount of times I've hit -r by mistake and regretted it..
    - michaelcampbell 10y ago
      I can. 0. There, more anecdata. Honestly though, I never use `-e` either. I keep a ~/.crontab and edit that, and then `crontab ~/.crontab`. Voila, backup/time machine/git friendly crontab.
    - dajohnson89 10y ago
      Have a cronjob that backs up your crontab?
    - benjojo12 10y ago
      I got bit by this once, and had to rescue the crontab out off the disk with GNU strings :(
- mooneater 10y ago
  first thing when logging into new server: place /etc under git. then loss of cron files (or any config file) is easily recovered from.
  - Drdrdrq 10y ago
    This is a brilliant idea - thank you!
    - mooneater 10y ago
      I cannot count the number of times this has helped or saved me. You can keep the /etc git repo local. Or if its a critical server, push to github private repo. Seeing a history of your /etc edits is a very reassuring feeling.
  - pferde 10y ago
    Except that crontabs are usually somewhere in /var. :)
    - mooneater 10y ago
      Which is why I only use system-wide crontabs, in /etc/cron.d Instead of per-user crontabs. Much easier to manage. With cron.d you can specify what user each cron entry should run as, so it is equivalent.
Animats 10y ago
crontab -e is the way to edit your cron. A similar command exists for editing the sudoers file which is visudo. This will ensure your configuration is a valid syntax as well as do an atomic swap of the file. And there's "vipw" for the password file. Each of them with their own separate updating bugs.

krrrh 10y ago

I'm surprised that people would edit cron in any other way, crontab -e is one of the first commands most intro to Linux manuals teaches. However crontab -r has to be one of the most poorly thought out commands in UNIX. It removes the cron file and since r is only one character over from e on qwerty keyboards it's a painful and surprising typo.

efiala 10y ago
what if you are managing the crons externally, eg puppet, crontab -e is not always option
- Godel_unicode 10y ago
  1. If you don't have a test process for changes made with puppet, this is hardly a problem with cron. 2. Puppet handled that parsing for you and will throw errors if your syntax is wrong
- hibbelig 10y ago
  Use /bin/cat as editor. That should work nicely from Puppet.
- _ao789 10y ago
  I can't tell you the amount of times I've hit -r by mistake and regretted it..
  - michaelcampbell 10y ago
    I can. 0. There, more anecdata. Honestly though, I never use `-e` either. I keep a ~/.crontab and edit that, and then `crontab ~/.crontab`. Voila, backup/time machine/git friendly crontab.
  - dajohnson89 10y ago
    Have a cronjob that backs up your crontab?
  - benjojo12 10y ago
    I got bit by this once, and had to rescue the crontab out off the disk with GNU strings :(
mooneater 10y ago
first thing when logging into new server: place /etc under git. then loss of cron files (or any config file) is easily recovered from.
- Drdrdrq 10y ago
  This is a brilliant idea - thank you!
  - mooneater 10y ago
    I cannot count the number of times this has helped or saved me. You can keep the /etc git repo local. Or if its a critical server, push to github private repo. Seeing a history of your /etc edits is a very reassuring feeling.
- pferde 10y ago
  Except that crontabs are usually somewhere in /var. :)
  - mooneater 10y ago
    Which is why I only use system-wide crontabs, in /etc/cron.d Instead of per-user crontabs. Much easier to manage. With cron.d you can specify what user each cron entry should run as, so it is equivalent.

Animats 10y ago

crontab -e is the way to edit your cron. A similar command exists for editing the sudoers file which is visudo. This will ensure your configuration is a valid syntax as well as do an atomic swap of the file. And there's "vipw" for the password file. Each of them with their own separate updating bugs.