Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #275391 > unrolled thread

Restarting cron after crontab update

Back to article view | Back to linux.debian.user

Contents

  Restarting cron after crontab update Roger Price <debian@rogerprice.org> - 2024-12-08 11:30 +0100
    Re: Restarting cron after crontab update Michael Kjörling <c9bc136c6063@ewoof.net> - 2024-12-08 12:10 +0100
    Re: Restarting cron after crontab update debian-user@howorth.org.uk - 2024-12-08 13:30 +0100
      Re: Restarting cron after crontab update Roger Price <debian@rogerprice.org> - 2024-12-08 14:20 +0100
        Re: Restarting cron after crontab update Greg Wooledge <greg@wooledge.org> - 2024-12-08 15:20 +0100
          Re: Restarting cron after crontab update Roger Price <roger@rogerprice.org> - 2024-12-09 15:50 +0100
            Re: Restarting cron after crontab update <tomas@tuxteam.de> - 2024-12-09 16:00 +0100
              Re: Restarting cron after crontab update Greg Wooledge <greg@wooledge.org> - 2024-12-09 16:40 +0100
                Re: Restarting cron after crontab update Roger Price <debian@rogerprice.org> - 2024-12-09 17:50 +0100
                User "nut" (Was Re: Restarting cron after crontab update) Roger Price <debian@rogerprice.org> - 2024-12-09 18:00 +0100
                Re: Restarting cron after crontab update Darac Marjal <lists-debian-user@bendel.debian.org> - 2024-12-09 18:10 +0100
                  Re: Restarting cron after crontab update Greg Wooledge <greg@wooledge.org> - 2024-12-09 19:50 +0100
              Re: Restarting cron after crontab update Greg Wooledge <greg@wooledge.org> - 2024-12-09 16:40 +0100
                Re: Restarting cron after crontab update Charles Curley <charlescurley@charlescurley.com> - 2024-12-09 18:00 +0100
              Re: Restarting cron after crontab update Charles Curley <charlescurley@charlescurley.com> - 2024-12-09 16:40 +0100

#275391 — Restarting cron after crontab update

With emacs I made a change to /etc/crontab on a Debian 11 workstation.  I have 
done this before successfully.  After the change I ran

  systemctl restart cron && systemctl status cron

But now the change doesn't take effect.

I tried systemctl reload cron, but got the reply "Failed to reload cron.service: 
Job type reload is not applicable for unit cron.service".

What is the correct way to get cron to read the new crontab ?

Thanks, Roger

[toc] | [next] | [standalone]

#275393

On 8 Dec 2024 11:19 +0100, from debian@rogerprice.org (Roger Price):
> What is the correct way to get cron to read the new crontab ?

Saving the crontab file.

It should be re-read automatically, with no need to restart a
system-level service.

Either you also did something else which you do not mention; or you
introduced an error in /etc/crontab as you edited it.

Note that the generally recommended way is to add a file in
/etc/cron.d instead of editing /etc/crontab. Doing so reduces the risk
of conflicts later.

-- 
Michael Kjörling
🔗 https://michael.kjorling.se

[toc] | [prev] | [next] | [standalone]

#275395

Roger Price <debian@rogerprice.org> wrote:
> With emacs I made a change to /etc/crontab on a Debian 11
> workstation.  I have done this before successfully.

When you say you made a change with emacs, what command did you run?
What you are supposed to do is use the command crontab to start the
editor of your choice. You should not start emacs and use it to edit a
cron file.

There is no need to restart cron yourself, as Michael said.

>  After the change I ran
>
>   systemctl restart cron && systemctl status cron
> 
> But now the change doesn't take effect.
> 
> I tried systemctl reload cron, but got the reply "Failed to reload
> cron.service: Job type reload is not applicable for unit
> cron.service".
> 
> What is the correct way to get cron to read the new crontab ?
> 
> Thanks, Roger
> 

[toc] | [prev] | [next] | [standalone]

#275396

On Sun, 8 Dec 2024, debian-user@howorth.org.uk wrote:

> Roger Price <debian@rogerprice.org> wrote:
>> With emacs I made a change to /etc/crontab on a Debian 11
>
> When you say you made a change with emacs, what command did you run?

  emacs /etc/crontab

> What you are supposed to do is use the command crontab to start the
> editor of your choice.

I rediscovered command  EDITOR=emacs crontab -e  and made my changes. 
Command crontab -l shows the updated file.  I'm waiting to see the result.

Thanks for reminding me.  Roger

As one gets older, one forgets the stuff one should remember, and remembers the 
stuff one should forget.

[toc] | [prev] | [next] | [standalone]

#275400

On Sun, Dec 08, 2024 at 11:19:52 +0100, Roger Price wrote:
> With emacs I made a change to /etc/crontab on a Debian 11 workstation.  I
> have done this before successfully.  After the change I ran
> 
>  systemctl restart cron && systemctl status cron
> 
> But now the change doesn't take effect.
> 
> I tried systemctl reload cron, but got the reply "Failed to reload
> cron.service: Job type reload is not applicable for unit cron.service".
> 
> What is the correct way to get cron to read the new crontab ?

Just saving the file is enough; you don't need to run a command
afterward.

What line did you add to /etc/crontab?  Please paste it here.  Note
that /etc/crontab uses a different format than personal crontab
files (there's an extra username field).


On Sun, Dec 08, 2024 at 14:11:50 +0100, Roger Price wrote:
> I rediscovered command  EDITOR=emacs crontab -e  and made my changes.
> Command crontab -l shows the updated file.  I'm waiting to see the result.
> 
> Thanks for reminding me.  Roger

That command edits your personal crontab file, which has the shorter
lines (no username field is needed, because all the jobs are run as
you).

I'm still suspecting you used the wrong format in one or both files,
so it would be helpful to know what line you added to each of them,
and why you were using /etc/crontab (system-wide) if your job was
going to run as you.  I'm not saying it's *wrong* to have all your
system-wide and personal jobs in one place, but it's non-traditional.

[toc] | [prev] | [next] | [standalone]

#275420

On Sun, 8 Dec 2024, Greg Wooledge wrote:

> What line did you add to /etc/crontab?  Please paste it here.  Note
> that /etc/crontab uses a different format than personal crontab
> files (there's an extra username field).

I added lines to /etc/crontab such as

  # Watch over the NUT heartbeat at 0803 hr every day
  3    8    * * *  nut    /usr/local/bin/heartbeat-watcher.sh > /dev/null 2>&1
  # Lets have Biff bark the hours
  0,1  0,12 * * *  rprice /mnt/home/rprice/bark/bark.sh  12 > /dev/null 2>&1
  ...
  0,1 11,23 * * *  rprice /mnt/home/rprice/bark/bark.sh  11 > /dev/null 2>&1

> That command edits your personal crontab file, which has the shorter
> lines (no username field is needed, because all the jobs are run as
> you).

I added a username, but crontab -e didn't complain.

> I'm still suspecting you used the wrong format in one or both files,
> so it would be helpful to know what line you added to each of them,

The personal lines I specified using crontab -e were also as shown above.

> and why you were using /etc/crontab (system-wide) if your job was
> going to run as you.  I'm not saying it's *wrong* to have all your
> system-wide and personal jobs in one place, but it's non-traditional.

It was clearly a misunderstanding on my part to have additional lines in 
/etc/crontab.  I have removed them and returned /etc/crontab to what it was when 
Debian 11 was installed. All my personal lines are now specified by "crontab -e" 
and can be seen in /var/spool/cron/crontabs/rprice

Roger

[toc] | [prev] | [next] | [standalone]

#275423

[Multipart message — attachments visible in raw view] — view raw

On Mon, Dec 09, 2024 at 03:24:06PM +0100, Roger Price wrote:
> On Sun, 8 Dec 2024, Greg Wooledge wrote:
> 
> > What line did you add to /etc/crontab?  Please paste it here.  Note
> > that /etc/crontab uses a different format than personal crontab
> > files (there's an extra username field).
> 
> I added lines to /etc/crontab such as
> 
>  # Watch over the NUT heartbeat at 0803 hr every day
>  3    8    * * *  nut    /usr/local/bin/heartbeat-watcher.sh > /dev/null 2>&1
>  # Lets have Biff bark the hours
>  0,1  0,12 * * *  rprice /mnt/home/rprice/bark/bark.sh  12 > /dev/null 2>&1
>  ...
>  0,1 11,23 * * *  rprice /mnt/home/rprice/bark/bark.sh  11 > /dev/null 2>&1
> 
> > That command edits your personal crontab file, which has the shorter
> > lines (no username field is needed, because all the jobs are run as
> > you).
> 
> I added a username, but crontab -e didn't complain.

I still fear your crontab won't do what you expect it to do.

Most probably cron will just see what you intended as a user
name as part of the command:

  rprice /mnt/home/rprice/bark/bark.sh  11 > /dev/null 2>&1

will run the command "rprice" on the args "/mnt..."; most of
the time this will be a "no such file or so-and-so", sometimes
it might lead to surprising results ;-)

And no, I don't think "crontab -e" will check whether that
command exists. For a multitude of reasons (most of which can
be subsumed under "the environment cron will run in isn't known
when editing the tab").

Cheers
-- 
t

[toc] | [prev] | [next] | [standalone]

#275428

On Mon, Dec 09, 2024 at 15:59:38 +0100, tomas@tuxteam.de wrote:
> On Mon, Dec 09, 2024 at 03:24:06PM +0100, Roger Price wrote:
> > I added lines to /etc/crontab such as
> > 
> >  # Watch over the NUT heartbeat at 0803 hr every day
> >  3    8    * * *  nut    /usr/local/bin/heartbeat-watcher.sh > /dev/null 2>&1

OK.  You have the correct format here.  Unfortunately, you've redirected
all the output and errors to /dev/null, so you won't know if it breaks,
or why.

You should, however, be able to find a log file (or journal) somewhere
on the system indicating that the job was attempted at 08:03.

If you want any more details (like why it's failing), get rid of the
redirections and let it email the output to you (or whoever "nut" is).

> > I added a username, but crontab -e didn't complain.
> 
> I still fear your crontab won't do what you expect it to do.
> 
> Most probably cron will just see what you intended as a user
> name as part of the command:
> 
>   rprice /mnt/home/rprice/bark/bark.sh  11 > /dev/null 2>&1
> 
> will run the command "rprice" on the args "/mnt..."; most of
> the time this will be a "no such file or so-and-so", sometimes
> it might lead to surprising results ;-)

This is all correct.  You (Roger) should remove the username field from
the "crontab -e" variant.  Beyond that, if your command isn't working
when run from cron, you will need to read the output.  So get rid of
those redirections, and let it email the output to you.

If your system doesn't have local email delivery working, then change
the redirections to write the output to a file, instead of /dev/null.
Then read what's in the file.

[toc] | [prev] | [next] | [standalone]

#275431

On Mon, 9 Dec 2024, Greg Wooledge wrote:

> On Mon, Dec 09, 2024 at 15:59:38 +0100, tomas@tuxteam.de wrote:
>
>>> I added a username, but crontab -e didn't complain.
>>
>> I still fear your crontab won't do what you expect it to do.
>> Most probably cron will just see what you intended as a user
>> name as part of the command:
>>
>>   rprice /mnt/home/rprice/bark/bark.sh  11 > /dev/null 2>&1
>>
>> will run the command "rprice" on the args "/mnt..."; most of
>> the time this will be a "no such file or so-and-so", sometimes
>> it might lead to surprising results ;-)
>
> This is all correct.  You (Roger) should remove the username field from
> the "crontab -e" variant.  Beyond that, if your command isn't working
> when run from cron, you will need to read the output.  So get rid of
> those redirections, and let it email the output to you.

I let cron e-mail me and saw a demonstration of what you predicted would happen 
if the username is specified.

E-mail with username specified:
   Subject: Cron <rprice@titan> rprice /mnt/home/rprice/bark/bark.sh   4
   /bin/bash: line 1: rprice: command not found

E-mail with no username
   Subject: Cron <rprice@titan> /mnt/home/rprice/bark/bark.sh   4
   Playing Sparc Audio '/mnt/home/rprice/bark/h4.au' : Mu-Law, Rate 8000 Hz, Mono

I have revised my "crontab -e" entirely, and I have once more the pleasure of 
hearing Biff bark the hours.

Thanks very much for your help, Roger

[toc] | [prev] | [next] | [standalone]

#275432 — User "nut" (Was Re: Restarting cron after crontab update)

On Mon, 9 Dec 2024, Greg Wooledge wrote:

> .. let it email the output to you (or whoever "nut" is).

nut is the user created by the NUT (Network UPS Tools) package which manages my 
UPS units.  Anyone who installs nut to manage UPS's will have this user.

Roger

[toc] | [prev] | [next] | [standalone]

#275434

[Multipart message — attachments visible in raw view] — view raw

On 09/12/2024 15:30, Greg Wooledge wrote:
> On Mon, Dec 09, 2024 at 15:59:38 +0100, tomas@tuxteam.de wrote:
>> On Mon, Dec 09, 2024 at 03:24:06PM +0100, Roger Price wrote:
>>> I added lines to /etc/crontab such as
>>>
>>>   # Watch over the NUT heartbeat at 0803 hr every day
>>>   3    8    * * *  nut    /usr/local/bin/heartbeat-watcher.sh > /dev/null 2>&1
> OK.  You have the correct format here.  Unfortunately, you've redirected
> all the output and errors to /dev/null, so you won't know if it breaks,
> or why.

A helpful tool here might be "cronic" (in the "cronic" package). 
"cronic" will swallow the output of the command it runs UNLESS that 
command exits with an error code.

So one would write:

3 8 * * * cronic /usr/local/bin/hearbeat-watcher.sh

and let's imagine the shell script does "echo Everything's okay ; exit 
0" once a day, then you don't get too many emails. But when it fails 
(echo Everything's not okay ; exit 1), then you DO get an email.

[toc] | [prev] | [next] | [standalone]

#275436

On Mon, Dec 09, 2024 at 17:08:31 +0000, Darac Marjal wrote:
> A helpful tool here might be "cronic" (in the "cronic" package). "cronic"
> will swallow the output of the command it runs UNLESS that command exits
> with an error code.
> 
> So one would write:
> 
> 3 8 * * * cronic /usr/local/bin/hearbeat-watcher.sh
> 
> and let's imagine the shell script does "echo Everything's okay ; exit 0"
> once a day, then you don't get too many emails. But when it fails (echo
> Everything's not okay ; exit 1), then you DO get an email.

That depends on the script exiting with an appropriate code.  May work,
may not.

If the "all's well" messages are printed to stdout, and the real errors
are printed to stderr, then it might be simpler just to redirect
stdout BUT NOT redirect stderr.

    3 8 * * * /usr/local/bin/heartbeat-watcher.sh >/dev/null

Then, if anything is written to stderr, cron will email it.

Of course, this depends on the script printing error messages to stderr.
May work, may not.

[toc] | [prev] | [next] | [standalone]

#275429

On Mon, Dec 09, 2024 at 08:30:16 -0700, Charles Curley wrote:
> On Mon, 9 Dec 2024 15:59:38 +0100
> <tomas@tuxteam.de> wrote:
> 
> > Most probably cron will just see what you intended as a user
> > name as part of the command:
> > 
> >   rprice /mnt/home/rprice/bark/bark.sh  11 > /dev/null 2>&1
> > 
> > will run the command "rprice" on the args "/mnt..."; most of
> > the time this will be a "no such file or so-and-so", sometimes
> > it might lead to surprising results ;-)
> 
> In which event cron will send a complaining email to the appropriate
> user. Since Mr. Price hasn't mentioned any such emails, I conjecture he
> is not monitoring his emails in /var/mail, and probably should be.

The redirections >/dev/null 2>&1 are discarding all the output, so there
is nothing to be sent to his email.

[toc] | [prev] | [next] | [standalone]

#275433

On Mon, 9 Dec 2024 10:31:38 -0500
Greg Wooledge <greg@wooledge.org> wrote:

> > In which event cron will send a complaining email to the appropriate
> > user. Since Mr. Price hasn't mentioned any such emails, I
> > conjecture he is not monitoring his emails in /var/mail, and
> > probably should be.  
> 
> The redirections >/dev/null 2>&1 are discarding all the output, so
> there is nothing to be sent to his email.

Doh! Of course. Well, removing those redirections might give a useful
diagnostic.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

[toc] | [prev] | [next] | [standalone]

#275430

On Mon, 9 Dec 2024 15:59:38 +0100
<tomas@tuxteam.de> wrote:

> Most probably cron will just see what you intended as a user
> name as part of the command:
> 
>   rprice /mnt/home/rprice/bark/bark.sh  11 > /dev/null 2>&1
> 
> will run the command "rprice" on the args "/mnt..."; most of
> the time this will be a "no such file or so-and-so", sometimes
> it might lead to surprising results ;-)

In which event cron will send a complaining email to the appropriate
user. Since Mr. Price hasn't mentioned any such emails, I conjecture he
is not monitoring his emails in /var/mail, and probably should be.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web