5 ms·

Crontab is an excellent example of situations where text files are superior. You are welcome to try to design a database schema that is safer or easier to use.

Crontab is an excellent example of situations where text files are superior. You are welcome to try to design a database schema that is safer or easier to use. Most of the things living under /etc are not databases. crontab certainly isn't: - Only a single "table" (no table-relations) - No standard database type exists for columns (how would you model the scheduling as database types, how would you model the shell command as database types, if not simply as sanitized strings) So you can't get integrity for free. Need a custom parser and some integrity checks. Not so difficult (yes, cron will give instant feedback for the unlikely case that you did something wrong) Re: editor, locking, access control: I have an editor and prefer it to writing SQL DML any day. File updates (rename(2)) are atomic, so no need for additional locking. And even if there is some broken tool writing to the old file instead of rename, the chances of that being simultaneous with a parse are microscopic. Don't overdesign. (there are many more things that can go wrong in a system that you can't possibly design out. Live with it). Access control: Standard file permission modes are just fine. More complex permission model would be a serious overdesign. You can get granularity by using separate crontabs. Checker: Never needed an additional tool to format the meaning as human-readable text. The syntax is a bit ugly but quite easy to remember and use.

cel1ne 10y ago
Not all databases follow a relational model with tables or schemas. I guess what he meant is that a key-value store would have some merits over files. Kinda like Window's registry.
- jstimpfle 10y ago
  He explicitly mentioned sqlite. Key-value stores could not improve on that since RDBMS generalize key-value.
- Zardoz84 10y ago
  Bad example. Windows registry is well know as a source of problems.
cma 10y ago
A cron job kicks off that makes the whole system unresponsive, undergoing heavy swap (updatedb used to do this and ran every night on many default systems). Someone edits a cron file in the most common editor, vim. On many systems it doesn't do an atomic swap on save without extra configuration: http://stackoverflow.com/questions/13563627/how-does-vim-save-files http://stackoverflow.com/questions/13563627/how-does-vim-sav... Now maybe your unresponsive, undergoing swap, system misses a cron job that was present in both edits. Opps. I'm not sure this could really play out, but the approach definitely sounds firmly on the "worse is better" side of the scale.
- krunaldo 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. 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

cel1ne 10y ago

Not all databases follow a relational model with tables or schemas. I guess what he meant is that a key-value store would have some merits over files. Kinda like Window's registry.

jstimpfle 10y ago
He explicitly mentioned sqlite. Key-value stores could not improve on that since RDBMS generalize key-value.
Zardoz84 10y ago
Bad example. Windows registry is well know as a source of problems.

cma 10y ago

A cron job kicks off that makes the whole system unresponsive, undergoing heavy swap (updatedb used to do this and ran every night on many default systems). Someone edits a cron file in the most common editor, vim. On many systems it doesn't do an atomic swap on save without extra configuration: http://stackoverflow.com/questions/13563627/how-does-vim-save-files http://stackoverflow.com/questions/13563627/how-does-vim-sav... Now maybe your unresponsive, undergoing swap, system misses a cron job that was present in both edits. Opps. I'm not sure this could really play out, but the approach definitely sounds firmly on the "worse is better" side of the scale.

krunaldo 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. 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