there already is a patch/bugfix for handling command options like "-q". I improved it a little bit to tolerate whitespaces between the user id and the option itself. I will attach a new version of "vixie-cron-4.1-commandline.patch" which is already included in the ebuild. Reproducible: Always Steps to Reproduce: 1. enter a crontab entry like */5 * * * * root -q echo "1" <- fails 2. remove all spaces between "root" and "-q" except one -> works
Created attachment 45080 [details, diff] improved version of vixie-cron-4.1-commandline.patch a really easy thing: tolerate whitespaces between the "user" field and command line options by calling "Skip_Blanks(ch, file)". This allows nicer formatting of your /etc/crontab when you intend to use some options like "-q" ;-)
Looks good to me. Aaron?
Yeah looks good from what I can see; I'll update the patch first thing in the morning unless Ciaran beats me to it ;p
All yours, I'm stuck on a wet string internet connection for the next few days and using cvs is seriously painful...
Went ahead and updated it. Leaving revision at r4 for something this minor. Thomas, thanks very much for the updated patch.
Thomas, It looks like there is a problem with the patch. I didn't notice it at first (shame on me for introducing it into a stable ebuild, btw), but it looks like one char too many gets getc()'d resulting in the first char of the command/option being chopped (and hence an invalid command being run). For example, it tries to run "est -x /usr/sbin/runcrons ..." from /etc/crontab. I first noticed yesterday morning (about 8hrs after I committed it) and immediately reverted the patch. Luckily, though, I caught it before a user did (well, no bugs were submitted anyways). After the call to Skip_Blanks(), ch is the first char of the command (or -), and so the next call to get_char is the 2nd char... so the obvious fix (you would think) would be to remove the extra call to get_char() since it is unnecessary (gdb has confirmed the above paragraph, btw). Now, here's the funky part and the reason I'm reopening rather than just quietly fixing. You can do what should be the fix yourself, but if you do, I'd keep a window with top open and and start cron with -n (stay in the foreground), so you can quickly SIGINT out of it, if you notice RSS is way up. I started it as I normally do via the init script and so didn't notice it was eating 400MB, just prior to my box thrashing itself to death (had to cold boot :/). gdb isn't showing anything abnormal. the most useful peace of info I have at this moment in time, is output from cron -x pars (debug output from the parsing code) and it looks like it's looping in the user's crontab for some reason. I am still working on it, but since I didn't get it fixed yet, I figured I should at least reopen this and give you a heads up.
oh dear, you are so right :-o I didn't look into the definition of the Skip_Blanks macro, shame on me. But the solution is quite simple: exchange the two "+" lines in the patch. I simply did the right things in the wrong order :-/ Thus the code should the look like this: --- ch = get_char(file); Skip_Blanks(ch, file) while (ch == '-') { --- This works fine for me, I verified it by printing out the result of the "ch = get_string(..." some lines below - nothing is missing. Thanks for the hint with "-n" !
It's always something stupid ;p I've been running it for the last 4 hours or so and everything looks groovy. Reclosing. Thanks again, Thomas.
