From: Henrik.Carlqvist@deadspam.com   
      
   On Sat, 22 Mar 2025 07:56:48 +0100, Marco Moock wrote:   
      
   > Hello!   
   >   
   > I want to run a cronjob.   
   >   
   > It currently (for testing purposes) looks like that:   
   >   
   > m@tr:~$ sudo cat /etc/cron.d/big-8   
   > SHELL=/bin/sh   
   > PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin   
   > *  *  *  *  *   root   echo "hallo"   
   > m@tr:~$   
   >   
   > m@tr:~$ sudo run-parts /etc/cron.d /etc/cron.d/big-8: line 3:   
   > check_big8.sh: command not found /etc/cron.d/big-8 failed.   
   > m@tr:~$   
   >   
   > It included a call for this script in the past, but I removed that. It   
   > still tries to run it. What causes that?   
      
   You need to differ between two things:   
      
   1) Script supposed to be called by a shell   
      
   2) Configuration files for cron jobs   
      
   A script supposed to be called by a shell can do things like setting   
   environment variables, call commands and evaluate wildcards. Such script   
   files usually start with a shebang (something like #!/bin/bash) telling   
   which shell to use to run the following commands.   
      
   The cron daemon reads its configuration files were the syntax is   
   explained in the man page of crontab. Basically all those lines in the   
   crontab configuration files can be comments or a very specific syntax   
   with five fields for time before a command to be called at that time.   
      
   To make things worse, there are different variants of crond out there and   
   they have different syntax for files below /etc/cron.d. The vixie cron   
   daemon used by some other distributions expect those configuration lines   
   to contain a username which says which user the job should be run as. The   
   Dillons crond used in Slackware does not expect any such username and run   
   all the cron jobs in those files as the user root. This makes sense as   
   only root will be able to put and edit files in that directory.   
      
   As explained in the man page for crontab all users can have their own   
   cron jobs and also root does have its own cron jobs in addition to the   
   jobs listed in files below /etc/cron.d. Those cron jobs are stored below /   
   var/spool/cron/crontabs, but the files in that directory should not be   
   edited by any other command than crontab.   
      
   So what have you done here? You have written a file with some lines   
   having a syntax for a shell script and one line having a syntax for the   
   configuration of a cron daemon not used by Slackware. You then call this   
   file with a command used to call shell scripts and that command starts a   
   shell which tries to run the file. When the shell comes to the line which   
   were intended as a configuration line for a cron job it parses those "*"   
   as wildcards which it expands to files in the current directory. Most   
   likely you had a file called check_big8.sh in your current directory, but   
   that file was not executable or not in your path so the shell failed to   
   execute it as a command.   
      
   Basically you cannot debug cron jobs by running them as shell files. You   
   can try to run the command of a cron job in a shell, but the environment   
   of the shell might differ from the environment in the cron daemon. Any   
   output sent to stdout or stderr from a cron job will be sent by mail to   
   the owner of the cron job.   
      
   regards Henrik   
      
   --- SoupGate-DOS v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)