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.
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):
Apr 28 21:12:35 p43k DEBIAN/CRON/USR/SBIN/CRON[10391]: (wolf) CMD (echo $(ls
/)| mail -s cron-test wolf)
I added the following line to env.c:
--- env.c.orig 2010-04-28 21:27:23.000000000 +0200
+++ env.c 2010-04-28 21:21:57.000000000 +0200
@@ -164,6 +164,7 @@
/* 2 fields from scanf; looks like an env setting
*/
+ Debug(DPARS, ("load_env: 2 fields from scanf; looks like an env
setting\n"))
/*
* process value string
Debugging output (line numbers inserted manually):
1 load_env, read <@reboot echo $(ls /)| mail -s cron-test wolf>
2 load_env, not 2 fields (1)
3 linenum=78
4 load_entry()...about to eat comments
5 load_entry()...about to parse command
6 linenum=79
7 load_entry()...returning successfully
8 linenum=80
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.
Cheers,
Wolf
--
Weisheit ist nicht das Ergebnis der Schulbildung, sondern des lebenslangen
Versuchs sie zu erwerben. - Albert Einstein
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
