Search this site


Metadata

Articles

Projects

Presentations

Ubuntu's cron package silently ignores files

I was trying to debug why my cronjobs weren't running in ubuntu. It should've been simple, right? Put a file in /etc/cron.d, and cron goes to town.

Except on Ubuntu (and probably Debian). Ubuntu and Debian have a horrible habit of patching upstream sources, excessively, to the point where they are no longer quite the upstream package. It's practices like this that caused the great Debian SSL/SSH key vulnerability and cause projects like Ion and Firefox (I think?) to have license clauses that prevent downstream packagers from calling megapatched version by the same name as the upstream project.

Vixie cron is not protected from the megapatching practice.

I did the normal debugging. You know, strace, etc. I saw cron stat my cron file, which was reduced to "* * * * * root logger HELLO WORLD" just to try anything. Nothing.

So, I download the source package with "apt-get source cron" and see the following:

% gzip -dc cron_3.0pl1-106ubuntu5.diff.gz | wc -l            
7228
7228 lines of patches. How big is cron?
nightfall(~/cron-3.0pl1) % wc -l *.c |tail -1
  4869 total
There are more lines of patches than there are lines of code. Pretty sure the README file says "Vixie Cron," but this kind of megapatching kind of takes the "Vixie" out of it.

The offending portion of the patch looks like this:

+static int valid_name (char *filename);

...

+               /* skipfile names with letters outside the set
+                * [A-Za-z0-9_-], like run-parts.
+                */
+               if (!valid_name(dp->d_name))
+                 continue;
+

...
Now I know why my cron jobs were being ignored: I typically name my cron files as 'something.cron' because it makes them more identifable in puppet and in svn.

I'm not sure what silly policy felt the need to mandate filenames in /etc/cron.d, but it needs to go. If it stays, it needs to actually be documented much more clearly. And no, I don't mean documenting it in some obscure manpage (like 'run-parts') that nobody reads or documenting it confusingly by saying "If using LSB, then this naming policy applies, if not using LSB, then this other naming policy applies"; I mean documenting it by having cron log "Ignoring <filename> due to <some policy>" - that's right, if you can't tell from the patch above, ubuntu's cron will silently ignore some files.

Explicit is better than implicit. Documentation doesn't always sync with code. Code is truth.

Further confusing the issue is the inconsistency in documenting this change. The crontab(1) manpage has a "DEBIAN SPECIFIC" section detailing this kind of thing (though I imagine it is quite incomplete). Update: There is no such section ('debian specific') in cron(8), though as commenters point out, this naming policy is documented in cron(8) but not clearly, in my opinion.

Sigh, what a waste of my time... Speaking of unexpected changes to decades-old system tools - FreeBSD knows what's up.

Finally, you'd think that out of all the 7228 lines of patches, one of them would fix this trivial bug still listed in crontab(1):

BUGS
       Although cron requires that each entry in a crontab end  in  a  newline  character,
       neither  the  crontab  command nor the cron daemon will detect this error. Instead,
       the crontab will appear to load normally. However, the command will never run.  The
       best choice is to ensure that your crontab has a blank line at the end.
Nope. I guess megapatching isn't for fixing bugs but instead for applying major changes and random, poorly documented and poorly thought-out policy changes to upstream code without forking the projects.