ok guys, ive lost out on more school becuase of this: ill make this real short and sweet: my cronjobs will NOT run unless i login as root, 'killall crond' then type crond again. sometimes i dont always remember to do that, therefore i dont get up for school. my crond starts @ startup from a script in /etc/rc.d/crond. the script reads as follows:

#!/bin/sh
# this script is for the cron daemon.
/usr/sbin/crond

my cronjobs are found in ~/ in a file called .mp3_alarm, and that reads as follows:

#!/bin/sh
mplayer -really-quiet -shuffle -playlist /mnt/fat32/Albums/.all.m3u


now, like i said these cronjobs run perfectly, but only if i restart it from root. the question is, why the hell does it not run correctly from start??

any help here would be greatly appreciated... i actually like getting to school ontime

Not sure but I notice you don't have full path for your mplayer command. Typically cron doesn't inherit a PATH variable from anywhere because it is started at boot as you noticed. I suspect the reason it works AFTER you restart crond is that the crond started from the command line by you DID inherity YOUR environment including $PATH.

Try modifying the script to have the full path of mplayer in it then do a reboot to see if it works as expected from the automatic start of cron.

By the way you can change the time the script runs in cron so that you can test it rather than having to wait until the next time you need to go to class.

hrmm, i thank you for your reply. however, if you are correct sir, then how would i get the crond that runs at startup to inherit MY path for mplayer (without redefining the path). however i will redo the script to see if it works.

thanks for the good words, ill let you guys know how i turn out.

The answer is "you wouldn't want to".

Cron is designed to run as a scheduling utility - not a user environment. You put the environment into the scripts you want to run OR you call the scripts in cron with the specific user whose environment you want them to have:
e.g. su - myuser -c "mycommand".
However there is no reason to put in a PATH statement that points to bin, /usr/bin, /usr/local/bin, /opt/whatever, $HOME/bin etc... if all you need is to know where "mplayer" is. Just put that in the script and you're done. Also you don't need the plethora of other environment variables ($HOME, $SH_HISTORY, $etc...) that you get when all you're trying to do is execute a single command.
If you DO need any other environment variables its best to hard code them into the script so that it will run no matter how the user's environment is or is not set.

PATH was mentioned only because many people say something like "When I run my script from the command line it works but when I put in cron it doesn't." (This by the way is also an issue for the startup scripts themselves.). Adding the full path for commands within the script is the usual fix.

Your post was slightly different in that instead of running the script you were restarting crond itself. This meant crond was inheriting a user envrionment so any process it spawned would have in turn inherited that. Its only because your post was slightly different that I said "not sure" even though I think it is the likely cause.

I'm sorry to say that I have the same problem with crond. I have to kill crond as root and restart it, before the shell script that I have as crontab entry will be executed . And I have put the complete path in it. The script ("hintergrundbild") has permissions set to 755 (rwxr-xr-x).
My crontab: