tag 437180 confirmed pending thanks
Wolf Wiegand wrote: > Hi Christian, > > Christian Kastner wrote: > >>> $ crontab -l >>> @reboot FOO=$(ls /); echo $FOO | mail w...@localdomain >>> @reboot FOO="asdf"; echo $FOO | mail w...@localdomain >>> >>> $ grep CRON /var/log/syslog | egrep "wolf|reboot" >>> Mar 8 11:35:10 denkbrett /usr/sbin/cron[2766]: (CRON) INFO (Running >>> @reboot jobs) >>> Mar 8 11:35:10 denkbrett /USR/SBIN/CRON[2802]: (wolf) CMD (FOO="asdf"; >>> echo $FOO | mail w...@localdomain) >> I tried the exact same crontab (s/wolf/testuser/) on a vanilla lenny, >> and my sid devel machine, and all worked as expected. >> >> Could I ask you to try this one more time? >> >> What's really weird is that it's just the line with the command >> substitution that fails. cron doesn't perform any kind of >> interpretation, it just passes on the entire command string to $SHELL -c >> (default /bin/sh). > > I retried this on my lenny machine, now cron wouldn't run either of the > two @reboot-jobs from above. I probably must have gotten something mixed > up in my last mail. Actually, I suspect it was just a side effect of the underlying cause (see below). I had the same problems reproducing my own testcase. > I did a little bit of digging around, the problem seems to be that the > @reboot lines are recognized as environment statements during startup > because of the equal-sign (such as in SHELL=/bin/sh, for example). I > tried this with the following crontab entries: > > @reboot echo $(ls /)| mail -s cron-test wolf > @reboot FOO="asdf"; echo $FOO| mail -s cron-test wolf > > syslog shows that the first command is executed, the second is not > (please disregard the weird DEBIAN/CRON/USR/..., I used a locally > built source package for debugging purposes): > 9 load_env, read <@reboot FOO="asdf"; echo $FOO| mail -s cron-test > wolf> > 10 load_env: 2 fields from scanf; looks like an env setting > 11 load_env, <@reboot FOO> <"asdf"; echo $FOO| mail -s cron-test > wolf> -> <@reboot FOO="asdf"; echo $FOO| mail -s cron-test wolf> > 12 linenum=81 > 13 ...load_user() done > > > In line 2 you can see that the first @reboot-line is not recognized as > an environment setting. In line 10 however, you can see that this line > is recognized as an environment setting. So, the lines that are not > being executed are never passed to $SHELL, because they are mistaken for > something else. As to why these lines are executed during normal > operation, I cannot tell. Many thanks for your detailed analysis; I would never have found the bug otherwise. The parser misidentifies lines in the form @interval ENV= if the separating character between @interval and ENV= is a TAB instead of SPACE(s). My .vimrc has "set expandtab", which is why I couldn't reproduce the issue. Fixing this specific issue would have been trivial, but I backported the parser from upstream-4.1 to our 3.0 instead ...which was trivial, too, and it may catch other gotchas. It will be included in the next upload. For now, the simplest workaround for you would be to separate the @interval specifiers from the ENVVARs with spaces. Thanks again, Christian
signature.asc
Description: OpenPGP digital signature
