From Newsgroup: alt.os.linux.slackware

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?
--
kind regards
Marco

Send spam to 1742626445muell@stinkedores.dorfdsl.de

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.slackware

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
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.slackware

Marco Moock <mm@dorfdsl.de> 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?

In addition to what Henrik said, the most common reason for "old
crontab entry continues to be run" is that you directly edited the
crontab file instead of using 'crontab' to launch the edit.

In addition to 'locking' the file against plural edits, the 'crontab'
command also signals the running cron daemon to reload the edited file
when you save the changes and exit the editor.

If you just directly edit the file on disk, you have changed the file
on disk, but the running deamon will still have in memory a copy of the
old file before you edited it.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.slackware

On 22.03.2025 11:57 Uhr Henrik Carlqvist wrote:

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.

Thanks for pointing that out, this was the issue.
--
kind regards
Marco

Send spam to 1742641021muell@stinkedores.dorfdsl.de

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.slackware

On 22.03.2025 15:25 Uhr Rich wrote:

If you just directly edit the file on disk, you have changed the file
on disk, but the running deamon will still have in memory a copy of
the old file before you edited it.

I see that the crond shipped in Slackware is much different from that
in Debian.
Issue is now solved, thanks for the hints.
--
kind regards
Marco

Send spam to 1742653539muell@stinkedores.dorfdsl.de

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.slackware

On Sat, 22 Mar 2025 15:25:39 +0000, Rich wrote:

If you just directly edit the file on disk, you have changed the file on disk, but the running deamon will still have in memory a copy of the old
file before you edited it.

nods



if logged in as marco: crontab -e <--- *always*, don't pico/vi/
mcedit/... whatever


if logged in as root: crontab -e -u marco


* * * * * /usr/bin/logger test > /dev/null 2>&1

(... spam the log with "test" every minute)


--- Synchronet 3.21d-Linux NewsLink 1.2