Hi All, I recently migrated my ISPConfig3 installation to a new server, and it is mostly working, with the exception of a few minor issues. One of which is that CRON jobs generated by ISPConfig do not work. Typically, ISPConfig will generate a file similar to this in /etc/cron.d: Code: MAILTO='' SHELL='/bin/sh' 0 6 * * * web129 /usr/bin/wget -q -t 1 -T 7200 -O /dev/null 'http://someaddress.com/somescript.php' * * * * * web129 /usr/bin/wget -q -t 1 -T 7200 -O /dev/null 'http://someaddress.com/somescript.php' CRON picks up on files created here just fine, and I've narrowed it down to the SHELL directive at the top of the file. If I comment out the SHELL='/bin/sh' then the job starts running happily. The /bin/sh shell works - I can switch between /bin/sh and /bin/bash without a problem. It strikes me as extremely strange that this directive would cause cron to choke, and stranger still that it doesn't throw up any errors in the syslog or anywhere else... Any ideas what might be going on there? Thanks!!!
by default /bin/sh is symlinked on debian to dash and not to bash. So you might want to check where /bin/sh actually links to. That could be the problem.
Hi sjau Good thinking - however I made sure I reconfigured the system to use bash, and doing a directory listing in /bin confirms this: Code: lrwxrwxrwx 1 root root 4 mar 10 17:33 sh -> bash Anybody else have any suggestions on how to debug this? :O) I guess my workaround would be to manually create Cron jobs from now on. But I always liked the convenience of the Cron management in ISPConfig and would be sad to be without it.
what OS and cron package/version? You could try setting MAILTO to your address and see if anything is emailed. maybe set SHELL to /usr/bin/env or to a debugging script that writes info to a temp file to examine. If that doesn't find any leads, I'd probably try to strace the cron daemon and follow what it does. You might want/need to disable other cronjobs (eg. ispconfig's server.sh job) to cut down on output/data to sift through.
