7 ms·
A cron pitfall that will probably snare you at least once in your career
- jerf 15y agoAsked 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 15y agoMy guess is they wanted to avoid running .dotfiles and #emacsbackup~ files and threw out the baby with the bathwater.
- pyre 15y agoAlso '.bak' or '.old'
- qntm 15y agoIsn't ".bak" a fairly logical file extension for a cron job intended to, e.g., perform backups?
- dexen 15y agoAre #emacsbackup~ files executable by default? If not, that's a very weak reason. (honestly I dunno; have never used EMACS yet)
- raldi 15y agoWell, # 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.
- dexen 15y agoWait, 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.
- ars 15y agoYes, 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.
- cperciva 15y agoI have no clue why run-parts does this; but BSD periodic doesn't.
- mikemaccana 15y agoYes, 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.
- cperciva 15y agoI can't speak for other BSDs, but FreeBSD's cron is still derived from Vixie cron.
- RexRollman 15y agoOpenBSD uses Vixie Cron as well.
- insipid 15y agoAccording 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/38022 https://bugs.launchpad.net/ubuntu/+source/debianutils/+bug/3... http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=68561 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=68561
- nbpoole 15y agoI posted a link (http://news.ycombinator.com/item?id=2701527 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 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=308911
- insipid 15y agoMy apologies; I must have missed the comments in between my first looking at it and posting my comment.
- tvon 15y agoI'd love to hear the rationale behind the dot restriction.
- chrisjsmith 15y agoBeen 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 15y agoI'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 15y agoThe 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.
- yock 15y agoI 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?
- nbpoole 15y agoClick and drag over the text with your mouse and you should be able to see it.
- bmunro 15y agoThat was the first thing I tried. It doesn't work for me in Chromium 12
- nbpoole 15y agoStrange. I'm running Chrome 12 on OS X and I have no issue (although the contrast is very poor).
- raldi 15y agoReally? I tried to set up the CSS so it would be white on black. What colors do you actually get?
- nbpoole 15y agoScreenshot: http://imgur.com/Uq9Fs http://imgur.com/Uq9Fs I'm just hoping I'm not color-blind :-P
- jsprinkles 15y agoAll of the spoiler CSS (Reddit-wide) broke for me a few Chromes ago. Running 14.0.797.0 now on OS X.
- trafficlight 15y ago
- nbpoole 15y agoI 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 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 15y agoThey could at least log the skipping, by default.
- jsprinkles 15y agoShhh! 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?
- ars 15y agoConsidering how often these files are run that would make for quite a noisy logfile.
- ck2 15y agoI don't believe CentOS distro has this problem? I have plenty of scripts and php and such running in crons all over the place.
- deleted 15y ago[deleted]
- jwr 15y agoThis 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.
- mseebach 15y agorun-parts is used in many places on linuxes (anywhere you see a .d directory) so this is not a cron pitfall.
- jsprinkles 15y agoYou're right. Upstart does this too (if you rename to .disabled in /etc/init the job will not be run).
- js2 15y agoFrustrating 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).
- tedunangst 15y agoThank 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.
- sliverstorm 15y agoIt's somewhat nifty, I suspect it originated as a way to allow new packages to easily add jobs to cron if they need
- gwern 15y agoThat'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.
- hollerith 15y ago>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 15y ago
- javanix 15y agoIt 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.
- xbryanx 15y agoI'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 15y agoWhy 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 15y agoAlso 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 15y agoTap 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 15y agoIt 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.
- technomancy 15y agoAnother 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".
- res0nat0r 15y agoSince 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...