Hacker News new | past | comments | ask | show | jobs | submit login
A cron pitfall that will probably snare you at least once in your career (reddit.com)
136 points by raldi on June 27, 2011 | hide | past | favorite | 67 comments



Frustrating Unix pitfall of the day: esoteric cron rules

This isn't a Unix pitfall, it's a Debian pitfall. Further, it's not inherent to cron, but to the /etc/cron.{hourly,daily,weekly,monthly} concept as implemented by Debian.

Scripts in these directories are run via /usr/bin/run-parts, which is invoked via /etc/crontab. It is Debian's run-parts that imposes the naming restriction. Red Hat's run-parts doesn't have this restriction (go take a look, it's a shell script).


>This isn't a Unix pitfall, it's a Debian pitfall.

And that is an example of why I do not run Debian any more: (1) it assumes that I have nothing better to do than learn all of the details of the Debian system and (2) as soon as some complication like this dots-in-filenames thing makes it into stable, it is very difficult to remove because most Debian maintainers consider it-might-break-existing-code a winning argument.


"It might break existing code" is usually a winning argument. It takes a very strong opposing argument to beat it. If you don't believe in this, I don't want to use any of your code.


I can see how server software needs to be more conservative about making changes. I'm glad I am not using server software anymore for my personal software environment.


On the other hand, CentOS 5 has run-parts, but it doesn't have a --help option or a manpage. The Debian one does.


What do you use instead?


Slackware. As usual, takes the good bits out of both RedHat's and Debian's run-parts. It allows .{whatever} but ignores obvious, well-known suffixes like .bak etc.

From man run-parts: run-parts automatically skips files with certain suffixes that are generally associated with backup or extra files. Any file that ends in one of these will be silently ignored: ~ ^ , .bak .new .rpmsave, .rpmorig .rpmnew .swp


CentOS/Redhat or you could go full Unix with FreeBSD. Lots of other options too.


I switched to OS X in 2009. At the point I had been running Linux for 12 years, and GNU and Emacs on proprietary Unix for the 5 years before that.


I was a Linux user since 1997, but switched to OS X in 2009.


Thank you for that clarification. I've been running shell scripts named .sh all the time without trouble. Of course, I run them from crontab. I'd never even heard of this /etc/cron.* thing.


It's somewhat nifty, I suspect it originated as a way to allow new packages to easily add jobs to cron if they need


That's what Krafft says in _The Debian System_, actually - that it would be a real mess if new packages all had to edit the same crontab to install and deinstall themselves, but a directory-based system was very clean.


Hey, when you only get 80 characters for the headline, certain things have to be glossed over.


I found an older bug report for Debian that sheds a little light on why this behavior is useful: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=308911

    I can understand not changing the behaviour wrt historical
    precedent: I have been told that people used to rely on the
    ignore-dot mechanism to disable things (e.g. mv foo foo.disabled).
At the end of the report, you can see they added the --regex flag to allow for user-defined filename validation.


They could at least log the skipping, by default.


Considering how often these files are run that would make for quite a noisy logfile.


Shhh! Don't make administrators' jobs easier! How else will we justify our insane salary and benefits?

Look at the bright side: this is a few days of debugging and difficult to explain to the people signing your check. Aren't you glad it's there now?


A few days debugging? How could this possibly take any more than 5 minutes to work out on your own? If it takes a few days then maybe you are in the wrong job.


I think "a few days" was an intentional exaggeration.


Asked there, but I'll tack it on here too: What is the purpose of that absurd-seeming restriction on file names? If you can drop arbitrary executables into directories on the file system, you've already "won", so I assume it's not security. I've read the run-parts man page, and that just pushes the problem back one level. If it's just to avoid running old files, that's an absurdly large hammer to hit that problem with.


My guess is they wanted to avoid running .dotfiles and #emacsbackup~ files and threw out the baby with the bathwater.


Also '.bak' or '.old'


Isn't ".bak" a fairly logical file extension for a cron job intended to, e.g., perform backups?


Are #emacsbackup~ files executable by default? If not, that's a very weak reason.

(honestly I dunno; have never used EMACS yet)


Well, # is actually used for emacs autosave files (or something else regarding open buffers). Making ~ backups is indeed on by default.

Then again, if you're editing files in /etc/ as root and using emacs to do so, you kinda deserve what you get.


Wait, my intented question was, `do those backup files have the executable permission bits set'? Not `do they hold valid input for interpreter/CPU'.

In Slackware's startup scripts, there's a good bunch of

  if [ -x SOME_FILE ]; then    # if the file is executable, run it
    ./SOME_FILE start
  fi
which makes it trivial to enable/disable various services by simply chmod +x SOME_FILE / chmod -x SOME_FILE. If EMACS' backup files were marked as not executable by the editor, that would be `case closed' for me, no need to pay extra attention to characters in file names.


Yes, backup files have the executable bit set. They have the same bits as the real file.

They are in fact created by renaming the real file to the backup name, then saving the real file and copying the permissions.


According to the summary on the Ubuntu bug: "Essentially, we don't want to allow a '.' because of .dpkg-old and .dpkg-dist files."

Is the implication that you can have .dpkg files in cron folders that you wouldn't want to try to execute?

https://bugs.launchpad.net/ubuntu/+source/debianutils/+bug/3... http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=68561


I posted a link (http://news.ycombinator.com/item?id=2701527) to a Debian bug that explains the rationale (aside from the historical behavior argument) a little better: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=308911


My apologies; I must have missed the comments in between my first looking at it and posting my comment.


I have no clue why run-parts does this; but BSD periodic doesn't.


Yes, it's not a bug in Vixie Cron (which I think BSD cron may use) but in the Linux distros (who are responsible for adding run-parts).

.py, .pl, .sh and (as people realize they'are actually writing bash scripts) .bash are standards people actually use. Having them break in what amounts to an include dir is bad mojo.


I can't speak for other BSDs, but FreeBSD's cron is still derived from Vixie cron.


OpenBSD uses Vixie Cron as well.


I think I'm missing something. The comments that appear as if they should contain the answers contain nothing. Have the answers been removed? Does Reddit's [spoiler] tag do fun javascript-y things that don't work on IE8? Or am I so obtuse and unobservant that I'm missing something obvious?


They show up as a hovertext in FF


useless on android


Yeah, it wasn't working on my Android phone either. Had to wait to get into work and try it with Chrome.


You simply highlight the blocked text to reveal it. The text is the same color as the background.


That was the first thing I tried, to no avail. I was able to see his response by going to his profile and hovering over the word "spoiler" in his comment stream. The word "spoiler" doesn't appear for me in the threaded comments and clicking through the word "spoiler" results in a 404.

Very strange.


That has to do with how spoiler tags are set up on that subreddit: the actual spoiler content is in the title attribute of the link and the href points to /s. The CSS for the subreddit uses an attribute selector to find links pointing to /s and styles them appropriately.

If you view the posts outside of the context of the subreddit, there's no special CSS, so the link appears normally with some title text that appears on hover.


Click and drag over the text with your mouse and you should be able to see it.


That was the first thing I tried. It doesn't work for me in Chromium 12


Me either. But if you double click on the block it will highlight the text.


Strange. I'm running Chrome 12 on OS X and I have no issue (although the contrast is very poor).


Really? I tried to set up the CSS so it would be white on black. What colors do you actually get?


Screenshot: http://imgur.com/Uq9Fs

I'm just hoping I'm not color-blind :-P


All of the spoiler CSS (Reddit-wide) broke for me a few Chromes ago. Running 14.0.797.0 now on OS X.


Another fun one is that if your file doesn't end in a newline, cron will silently ignore the last line! Lost a couple days of production data at my last job due to that "feature".


IIRC, OpenBSD has some similar issues with PF rules, and perhaps other configuration files as well.

I can't remember if it refuses to parse the file or ignores the last line, but it's not a fun thing to bump against.


what editor are you using that doesn't add a newline?


run-parts is used in many places on linuxes (anywhere you see a .d directory) so this is not a cron pitfall.


You're right. Upstart does this too (if you rename to .disabled in /etc/init the job will not be run).


Since everyone should hopefully know /etc/cron* is a nonstandard cron directory, and an addon from Debian, it would be hopeful that you would also have discovered the relevant documentation as why this is, ie run-parts(8), like mentioned.

The manpage states you can pass --test <dir> and it will show you all the scripts it would have run. This should have been something done before any assumption was made as to this working off the bat.

On my systems now, or old Solaris machines I used to admin, I would always do an "at now <script>" to make sure there were not any $PATH issues before putting the script in production. I've always tested to make sure the generic skeleton of the script would work before assuming anything...


I'd love to hear the rationale behind the dot restriction.


It is kind of amazing how much this explains.

I thought I was doing well when I finally learned to remember the "no cron files that don't include an empty newline" rule.


This bit me as well. It is particularly annoying, as it takes forever to actually find the problem.

In addition to that, the restriction is silly and utterly pointless.


I don't believe CentOS distro has this problem?

I have plenty of scripts and php and such running in crons all over the place.


I've been using Jenkins to do every single thing I used to do in cron these days. Lots easier to visualize execution, and catch potential errors. More overhead, yes. Saved me tons of time, yes.


Why the devil can't I see certain text? I'm not a user of reddit so is this some kind of joke? I'm reading this on my iPhone.


Also on an iPhone. The reason is they're using a 'spoiler' tag that hides the text until it is selected. Unfortunately we can't do that...


Tap the text and it will become visible, then it navigates to reddit.com/s (no idea why). Then click back and the text will still be readable (just confirmed on my iPhone 4)


It is a hack using links.

It is formatted like this (IIRC):

  [spoiler](/s"More goes here")
then in CSS there is a match for url[href=/s] that provides the onmouseover stuff.


Been there done that. It's very annoying indeed. I wish things were slightly less finicky in *NIX platforms as a rule. They need a serious de-crufting session (plan 9 looks very much less crufty).


I've been hit with this problem before and had never found an explanation why some scripts worked and some didn't.

I eventually just added it to the crontab of a user and that was that, but I'm so glad to finally know WHY.

This is such an arcane restriction and its really hard to debug since there are no errors anywhere.


The lack of errors was annoying and counterintuitive. I like the usual UNIX mantra of blow up noisily if an assumption is made but it just doesn't happen there.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: