Am 23.04.2016 um 14:05 schrieb Poggenpohl, Daniel:
Hello everyone, Preface: My system is Solaris 11.2/11.3 X86/64. I'm changing some cronjobs which previously ran as root which surely isn't really necessary. I entered some cronjob in the crontab for the apache and wondered why it didn't execute. I also wondered where the heck I could see what was wrong? I even thought that maybe the cronjob isn't even tried to run because the apache user doesn't have login enabled and has no password set. Well, after googling a lot, I found out about /var/cron/log and /var/mail/apache, which got me less helpful information (The script was executed, but got rc=1), and more helpful information (real error messages which helped determine the cause). One of the error messages was that the apache user couldn't change directory to his home dir, /export/home/apache. That's correct, because the apache user doesn't need a home dir, because he isn't a real user. But the script didn't work without me making the directory for the apache user. Is there some way to prevent this? My cronjob was just "runSomeScript.sh >> script.out", to test it.
I suggest having a read of "man cron" and "man crontab". The latter contains the following paragraph:
The shell is invoked from your $HOME directory with an arg0 of sh. Users who desire to have their .profile executed must explicitly do so in the crontab file. cron supplies a default environment for every shell, defining HOME, LOGNAME, SHELL(=/bin/sh), TZ, and PATH. The default PATH for user cron jobs is /usr/bin; while root cron jobs default to /usr/sbin:/usr/bin. The default PATH can be set in /etc/default/cron (see cron(1M)).So "The shell is invoked from your $HOME directory" describes the observed behavior. So I expect there's no way to prevent it.
You can of course run the script as root user and "su" inside the script, but that doesn't actually sound better. If the script only needs read access to files used by apache, like for log reporting, you can design a separate user to run that task. The correct solution might depend on what you want to achieve with "runSomeScript.sh".
Regards, Rainer --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx