
A cron pitfall that will probably snare you at least once in your career - raldi
http://www.reddit.com/r/raldi/comments/i8z20/frustrating_unix_pitfall_of_the_day_esoteric_cron/
======
js2
_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).

~~~
hollerith
>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.

~~~
ramidarigaz
What do you use instead?

~~~
Nick_C
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

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

~~~
raldi
They could at least log the skipping, by default.

~~~
jsprinkles
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?

~~~
kaerast
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.

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

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

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

~~~
pyre
Also '.bak' or '.old'

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

------
yock
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?

~~~
randombit
They show up as a hovertext in FF

~~~
gcb
useless on android

------
technomancy
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".

~~~
oasisbob
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.

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

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

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

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

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

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

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

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

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

~~~
whiskers
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...

~~~
city41
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)

~~~
X-Istence
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.

------
chrisjsmith
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).

~~~
bshep
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.

~~~
chrisjsmith
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.

