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

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

questions about cron.daily

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

Contents

  questions about cron.daily coreyh@free.fr - 2023-04-06 13:40 +0200
    Re: questions about cron.daily Greg Wooledge <greg@wooledge.org> - 2023-04-06 13:50 +0200
    Re: questions about cron.daily Andy Smith <andy@strugglers.net> - 2023-04-06 17:40 +0200
      Re: questions about cron.daily Fred <fred@blakemfg.com> - 2023-04-06 18:40 +0200
        Re: questions about cron.daily Pierre Frenkiel <frenkiel@gmail.com> - 2023-04-06 18:50 +0200
          Re: questions about cron.daily "Thomas Schmitt" <scdbackup@gmx.net> - 2023-04-06 19:10 +0200
            Re: questions about cron.daily Alexis Grigoriou <alexis@nanoid.net> - 2023-04-06 20:30 +0200
          Re: questions about cron.daily Fred <fred@blakemfg.com> - 2023-04-06 21:30 +0200
            Re: questions about cron.daily David Wright <deblis@lionunicorn.co.uk> - 2023-04-07 00:50 +0200
              Re: questions about cron.daily Greg Wooledge <greg@wooledge.org> - 2023-04-07 01:00 +0200
                Re: questions about cron.daily <tomas@tuxteam.de> - 2023-04-07 07:10 +0200
                  Re: questions about cron.daily Alex King <alex@rimuhosting.com> - 2023-04-08 02:20 +0200
                    Re: questions about cron.daily "Andrew M.A. Cater" <amacater@einval.com> - 2023-04-08 11:10 +0200
                      Re: questions about cron.daily Michel Verdier <mv524@free.fr> - 2023-04-08 11:20 +0200
                        Re: questions about cron.daily Greg Wooledge <greg@wooledge.org> - 2023-04-08 14:40 +0200
                          Re: questions about cron.daily Max Nikulin <manikulin@gmail.com> - 2023-04-08 17:20 +0200
                          Re: questions about cron.daily Kushal Kumaran <kushal@locationd.net> - 2023-04-08 17:20 +0200
                            Re: questions about cron.daily Max Nikulin <manikulin@gmail.com> - 2023-04-08 19:00 +0200
                              Re: questions about cron.daily Michel Verdier <mv524@free.fr> - 2023-04-09 10:00 +0200
                                Re: questions about cron.daily Max Nikulin <manikulin@gmail.com> - 2023-04-11 11:20 +0200
                          Re: questions about cron.daily Michel Verdier <mv524@free.fr> - 2023-04-09 10:00 +0200
                Re: questions about cron.daily Richard Hector <richard@walnut.gen.nz> - 2023-04-07 18:00 +0200
                Re: questions about cron.daily Anssi Saari <as@sci.fi> - 2023-04-07 18:00 +0200
                  Re: questions about cron.daily Cindy Sue Causey <butterflybytes@gmail.com> - 2023-04-07 23:50 +0200
                Re: questions about cron.daily David Wright <deblis@lionunicorn.co.uk> - 2023-04-09 18:10 +0200
                  Re: questions about cron.daily zithro <slack@rabbit.lu> - 2023-04-09 21:50 +0200
                    Re: questions about cron.daily David Wright <deblis@lionunicorn.co.uk> - 2023-04-10 03:30 +0200
                      Re: questions about cron.daily davidson <davidson@freevolt.org> - 2023-04-10 04:30 +0200
                      Re: questions about cron.daily Michel Verdier <mv524@free.fr> - 2023-04-10 08:40 +0200
                        Re: questions about cron.daily David Wright <deblis@lionunicorn.co.uk> - 2023-04-11 05:50 +0200
                      Re: questions about cron.daily zithro <slack@rabbit.lu> - 2023-04-10 17:50 +0200
                        Re: questions about cron.daily David Wright <deblis@lionunicorn.co.uk> - 2023-04-11 05:50 +0200
        Re: questions about cron.daily Tom Furie <tom@furie.org.uk> - 2023-04-06 19:00 +0200
        Re: questions about cron.daily Michel Verdier <mv524@free.fr> - 2023-04-06 19:10 +0200
        Re: questions about cron.daily Greg Wooledge <greg@wooledge.org> - 2023-04-06 19:50 +0200
        Re: questions about cron.daily Stefan Monnier <monnier@iro.umontreal.ca> - 2023-04-06 19:50 +0200
        Re: questions about cron.daily davidson <davidson@freevolt.org> - 2023-04-06 23:30 +0200
          Re: questions about cron.daily ken@openmbox.net - 2023-04-07 02:20 +0200
            Re: questions about cron.daily Tom Furie <tom@furie.org.uk> - 2023-04-07 02:30 +0200
              Re: questions about cron.daily Dan Ritter <dsr@randomstring.org> - 2023-04-07 03:50 +0200

Page 2 of 2 — ← Prev page 1 [2]

#256937

Le 8 avril 2023 Greg Wooledge a écrit :

>> systemd user files can be put in ~/.config/systemd/user/ where you can
>> use git directly
>
> Have you ever actually *made* a systemd --user unit file?  If so, for
> what purpose?

$ find .config/systemd/
.config/systemd/
.config/systemd/user
.config/systemd/user/xsession.target.requires
.config/systemd/user/xsession.target.requires/dwm.service
.config/systemd/user/dwm.service
.config/systemd/user/xsession.target
.config/systemd/user/default.target.wants
.config/systemd/user/default.target.wants/pipewire.service
.config/systemd/user/default.target.wants/pipewire-pulse.service
.config/systemd/user/sockets.target.wants
.config/systemd/user/sockets.target.wants/pipewire.socket
.config/systemd/user/sockets.target.wants/pipewire-pulse.socket
.config/systemd/user/pulseaudio.service
.config/systemd/user/pipewire.service.wants
.config/systemd/user/pipewire.service.wants/wireplumber.service
.config/systemd/user/fetchmail.service

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

#256837

On 7/04/23 10:54, Greg Wooledge wrote:
> On Thu, Apr 06, 2023 at 05:45:08PM -0500, David Wright wrote:
>> Users (including root) write their crontabs anywhere they like,
>> typically in a directory like ~/.cron/.
> 
> Is that... normal?  I can't say I've ever seen anyone keep a private
> copy of their crontab in their home directory like that.
> 
> Most people just use "crontab -e" to edit the system's copy of their
> personal crontab...

Perhaps if they want to keep it in version control?

Richard

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

#256838

Greg Wooledge <greg@wooledge.org> writes:

> On Thu, Apr 06, 2023 at 05:45:08PM -0500, David Wright wrote:
>> Users (including root) write their crontabs anywhere they like,
>> typically in a directory like ~/.cron/.
>
> Is that... normal?  I can't say I've ever seen anyone keep a private
> copy of their crontab in their home directory like that.

I don't know if it's normal but sounds like a good practice, to have a
backup of your crontab. I've been bitten by this sometime when my old
shell provider retired a system and I had no copy of my crontab. My home
dir was not affected by that retirement since those were all NFS mounted
from a different server.

I think they did dig out my crontab from tape when I asked.

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

#256844

On 4/7/23, Anssi Saari <as@sci.fi> wrote:
> Greg Wooledge <greg@wooledge.org> writes:
>
>> On Thu, Apr 06, 2023 at 05:45:08PM -0500, David Wright wrote:
>>> Users (including root) write their crontabs anywhere they like,
>>> typically in a directory like ~/.cron/.
>>
>> Is that... normal?  I can't say I've ever seen anyone keep a private
>> copy of their crontab in their home directory like that.
>
> I don't know if it's normal but sounds like a good practice, to have a
> backup of your crontab. I've been bitten by this sometime when my old
> shell provider retired a system and I had no copy of my crontab. My home
> dir was not affected by that retirement since those were all NFS mounted
> from a different server.


I like mine there. I haven't tried crontab yet, but I've put other
things at that location. It's more easily transferable without having
to look for or remember any personalizations. I think it was building
via npm that made it a comfortable, memorable CHOICE.

The .local directory is coming to mind quicker for me these days.
/opt, too, thanks to [upstream?] Chrome educating me that it's a nice,
empty, less trafficked location to quickly peek at specifically
installed packages.

There's also /usr/local that makes it easier to more quickly remember
packages that are specifically installed favorites for whatever
reason. Among /usr/local's potential plusses is that it's about root
permissions whereas putting its same contents in .local means mixing
root and user.

Mixing directories of varying permissions is no biggie for seasoned
users but can quickly mangle things for newer ones. I mangled mine a
long time ago when I got the bright idea to "chown" my user's entire
~/. We.. try not to do that anymore. What a mess. :)

It's all about available cognitive abilities while computing for my usage case..

Cindy :)

N.B. because it might catch the eye of a curious newbie: I don't do
npm these days. I had fun while the experience lasted. There were some
scary security issues a couple years back because it's such a wide
open space out there. NPM's security was serious enough that it was a
US-CERT advisement. The original is still sitting in my inbox:

https://www.cisa.gov/news-events/alerts/2021/10/22/malware-discovered-popular-npm-package-ua-parser-js

-- 
Talking Rock, Pickens County, Georgia, USA
* runs with birdseed *

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

#256982

On Thu 06 Apr 2023 at 18:54:31 (-0400), Greg Wooledge wrote:
> On Thu, Apr 06, 2023 at 05:45:08PM -0500, David Wright wrote:
> > Users (including root) write their crontabs anywhere they like,
> > typically in a directory like ~/.cron/.
> 
> Is that... normal?  I can't say I've ever seen anyone keep a private
> copy of their crontab in their home directory like that.

Well, it's pretty normal if you use the first form of the command,
though there's no special need for it to be either in the home
directory or private.

> Most people just use "crontab -e" to edit the system's copy of their
> personal crontab...
> 
> > They then have to be installed
> > with crontab, which copies them into /var/spool/cron/crontabs/.
> 
> ... which lives there.

That's the workflow I might have used thirty years ago when I was
a plain old user of a university unix system with likely zero to
one lines of crontab and no need to think about backups. But that's
the old normal, which I'd find rather inflexible now. For example,
if you're busy editing crontab and it's time to go home, then you
either save it and it immediately becomes the active copy, or you
abandon editing, or you save it to some file before abandoning.
Say what? Isn't that a private copy?

Next month, or whenever, I'll be installing bookworm into the other
root partition on this machine. I'll want to copy (and preen, maybe)
my personal crontab from bullseye into bookworm.

IOW, while I run crontab -e on bookworm, inside my emacs session,
I want a subshell to run crontab -l, but the latter has to run on
bullseye in order to pick up the old crontab. I'm not sure how
I would do that.

Before very long, I'll be travelling again, taking one of my
laptops with me. It's roles at home and away are completely
different, so I switch crontabs for the duration, not with
crontab -e but with crontab ~/.cron/<appropriate-crontab>.
And that command is in a script that takes care of other
changes that need to be made for its travelling role.

I populate my ~/.cron directory with anything to do with cron,
like the scripts¹ that some crontab entries run, the crontabs
that I push to my other machines, and a copy of root's crontab
for when the occasion might arise to migrate a personal job to
being a systemwide one. And as it's all under my home directory,
it gets backed up too. (I don't backup /var/spool/.)

I also keep there the ephemeral files that control unattended
recording of live radio (via LineInput), because that system is
driven by a cron job running each minute. So an empty file like
.cron/2023-04-09-06-55-rk2wav-190 would record three hours on
Sunday morning. (I've been running this for over two decades,
though it doesn't get a fraction of the use that it did in the
days before BBC iplayer.)

¹ ISTR you had misgivings about that a couple of years ago.

Cheers,
David.

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

#256988

> IOW, while I run crontab -e on bookworm, inside my emacs session,
> I want a subshell to run crontab -l, but the latter has to run on
> bullseye in order to pick up the old crontab. I'm not sure how
> I would do that.

Try running :
ssh user@bullseye crontab -l

It will locally list the crontab from remote user "user".

Note I've never used emacs, so dunno if ssh is allowed !

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

#256991

On Sun 09 Apr 2023 at 21:48:22 (+0200), zithro wrote:
> > IOW, while I run crontab -e on bookworm, inside my emacs session,
> > I want a subshell to run crontab -l, but the latter has to run on
> > bullseye in order to pick up the old crontab. I'm not sure how
> > I would do that.
> 
> Try running :
> ssh user@bullseye crontab -l
> 
> It will locally list the crontab from remote user "user".
> 
> Note I've never used emacs, so dunno if ssh is allowed !

In case it's not clear, bullseye and bookworm are Debian distribution
codenames, not hostnames. I can't edit my crontab on a newly installed
bookworm system while simultaneously listing my old crontab on the old
bullseye system on the same computer.

The machine is set up to dual boot (currently bullseye and buster),
but not simultaneously!

Even for the same username, the crontab on one computer differs from
that on another, as the machines have different roles.

Cheers,
David.

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

#256993

On Sun, 9 Apr 2023 David Wright wrote:
> On Sun 09 Apr 2023 at 21:48:22 (+0200), zithro wrote:
>> [Previously David "Between-the-Lines" Wright wrote:]
>>> IOW, while I run crontab -e on bookworm, inside my emacs session,
>>> I want a subshell to run crontab -l, but the latter has to run on
>>> bullseye in order to pick up the old crontab. I'm not sure how I
>>> would do that.

"So it's a good thing I don't need to, since I've got all the
materials I need in my home directory, under ~/.cron"

>> Try running :
>> ssh user@bullseye crontab -l
>>
>> It will locally list the crontab from remote user "user".
>>
>> Note I've never used emacs, so dunno if ssh is allowed !

I too saw a plea for halp at first. At first I was derping out a reply
"Well David, since the bullseye system isn't running, you just
mount..."

But nope. Mirage!

Just rhetorical puzzlement implying an unspoken conclusion: "And
*that's* why we keep all the cron things on our home partition."

-- 
Hackers are free people. They are like artists. If they are in a good
mood, they get up in the morning and begin painting their pictures.
-- Vladimir Putin

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

#257000

Le 10 avril 2023 David Wright a écrit :

> In case it's not clear, bullseye and bookworm are Debian distribution
> codenames, not hostnames. I can't edit my crontab on a newly installed
> bookworm system while simultaneously listing my old crontab on the old
> bullseye system on the same computer.
>
> The machine is set up to dual boot (currently bullseye and buster),
> but not simultaneously!

You can boot on one system and mount the other system partition to
easily compare both.

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

#257031

On Mon 10 Apr 2023 at 08:31:16 (+0200), Michel Verdier wrote:
> Le 10 avril 2023 David Wright a écrit :
> 
> > In case it's not clear, bullseye and bookworm are Debian distribution
> > codenames, not hostnames. I can't edit my crontab on a newly installed
> > bookworm system while simultaneously listing my old crontab on the old
> > bullseye system on the same computer.
> >
> > The machine is set up to dual boot (currently bullseye and buster),
> > but not simultaneously!
> 
> You can boot on one system and mount the other system partition to
> easily compare both.

You're right, though technically that depends on your friendly
sysadmin to mount it. (Of course, typically, that's me.) But
it doesn't address the other advantages of a separate file.

Cheers,
David.

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

#257003

On 10 Apr 2023 03:23, David Wright wrote:
> On Sun 09 Apr 2023 at 21:48:22 (+0200), zithro wrote:
>>> IOW, while I run crontab -e on bookworm, inside my emacs session,
>>> I want a subshell to run crontab -l, but the latter has to run on
>>> bullseye in order to pick up the old crontab. I'm not sure how
>>> I would do that.
>>
>> Try running :
>> ssh user@bullseye crontab -l
>>
>> It will locally list the crontab from remote user "user".
>>
>> Note I've never used emacs, so dunno if ssh is allowed !
> 
> In case it's not clear, bullseye and bookworm are Debian distribution
> codenames, not hostnames.

In case it's not clear, to distinguish hosts in help messages, it's easy 
to refer to a host using its distro/codename. I have no idea how you 
name your hosts, nor is it useful for the conversation. I thought you 
could do the name translation by yourself.

> I can't edit my crontab on a newly installed
> bookworm system while simultaneously listing my old crontab on the old
> bullseye system on the same computer.
> The machine is set up to dual boot (currently bullseye and buster),
> but not simultaneously!

Missed that information. So it's even easier.
Mount the /var partition of bullseye on bookworm.
Go to /MOUNTPOINT/var/spool/cron/crontabs
Done.

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

#257032

On Mon 10 Apr 2023 at 17:39:57 (+0200), zithro wrote:
> On 10 Apr 2023 03:23, David Wright wrote:
> > On Sun 09 Apr 2023 at 21:48:22 (+0200), zithro wrote:
> > > > IOW, while I run crontab -e on bookworm, inside my emacs session,
> > > > I want a subshell to run crontab -l, but the latter has to run on
> > > > bullseye in order to pick up the old crontab. I'm not sure how
> > > > I would do that.
> > > 
> > > Try running :
> > > ssh user@bullseye crontab -l
> > > 
> > > It will locally list the crontab from remote user "user".
> > > 
> > > Note I've never used emacs, so dunno if ssh is allowed !
> > 
> > In case it's not clear, bullseye and bookworm are Debian distribution
> > codenames, not hostnames.
> 
> In case it's not clear, to distinguish hosts in help messages, it's
> easy to refer to a host using its distro/codename. I have no idea how
> you name your hosts, nor is it useful for the conversation. I thought
> you could do the name translation by yourself.

In case it's not clear, to distinguish root filesystems in help
messages, it's easy to refer to a rootfs using its distro/codename.

For hostnames, I tend to follow RFCs 1178 and 2100. :)

Cheers,
David.

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

#256813

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

On Thu, Apr 06, 2023 at 09:02:15AM -0700, Fred wrote:
> I also would like to know when cron.daily scripts run.  Greg's command does
> not appear to reveal the time for that script.  I ran Greg's command and got
> the same result.

Then you need to read the documentation for cron. I'd suggest beginning with
'man 5 crontab' for the details of a crontab entry.

Cheers,
Tom

-- 
Here there be tygers.

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

#256814

Le 6 avril 2023 Fred a écrit :

> I also would like to know when cron.daily scripts run.  Greg's command does
> not appear to reveal the time for that script.  I ran Greg's command and got
> the same result.

Greg shows it:
unicorn:~$ grep daily /etc/crontab
25 6    * * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )

which means runs at 6:25 each day

to get meanings of each col:
man 5 crontab

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

#256816

On Thu, Apr 06, 2023 at 01:42:33PM -0400, Stefan Monnier wrote:
> > I also would like to know when cron.daily scripts run.  Greg's command does
> > not appear to reveal the time for that script.  I ran Greg's command and got
> > the same result.
> 
> As explained, his command's output does show the actual time, but
> I don't think it's the whole story: AFAIK the actual time can be
> different for example if you installed `anacron`, and I hope that's also
> true if you installed `systemd-cron`.
> 
> I say "I hope", because some of my machines I basically always OFF at
> that time.

In that case, I'd recommend changing the start time in /etc/crontab to
some time when your machines are likely to be on, but idle.  If there's
no such time, well, then you're looking at the alternatives like anacron
which are designed for such situations.

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

#256817

> I also would like to know when cron.daily scripts run.  Greg's command does
> not appear to reveal the time for that script.  I ran Greg's command and got
> the same result.

As explained, his command's output does show the actual time, but
I don't think it's the whole story: AFAIK the actual time can be
different for example if you installed `anacron`, and I hope that's also
true if you installed `systemd-cron`.

I say "I hope", because some of my machines I basically always OFF at
that time.


        Stefan

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

#256823

On Thu, 6 Apr 2023 Fred wrote:
[trimmed]
> I also would like to know when cron.daily scripts run.  Greg's command does 
> not appear to reveal the time for that script.  I ran Greg's command and got 
> the same result.

  $ grep -FA7 "Example of job definition" /etc/crontab ; grep daily /etc/crontab
  # Example of job definition:
  # .---------------- minute (0 - 59)
  # |  .------------- hour (0 - 23)
  # |  |  .---------- day of month (1 - 31)
  # |  |  |  .------- month (1 - 12) OR jan,feb,mar,apr ...
  # |  |  |  |  .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat
  # |  |  |  |  |
  # *  *  *  *  * user-name command to be executed
  25 6    * * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )

-- 
You shall also keep a trowel in your equipment. With it, when you go
outside to ease nature, you shall first dig a hole and afterward cover
up your excrement. Since the Lord, your God, journeys along within
your camp [and would be displeased to step in it] -- Deuteronomy 23

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

#256828

On 2023-04-07 05:20, davidson wrote:

>  25 6    * * *   root    test -x /usr/sbin/anacron || ( cd / && 
> run-parts --report /etc/cron.daily )

Are the time format in /etc/crontab just random? why they are 6:25, 6:47 
etc?


-- 
Ken Peng
https://kenpeng.pages.dev/

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

#256829

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

On Fri, Apr 07, 2023 at 08:05:18AM +0800, ken@openmbox.net wrote:
> Are the time format in /etc/crontab just random? why they are 6:25, 6:47
> etc?

They aren't *random*, though they are somewhat arbitrary. The daily tasks
run at 6:25, a time chosen by someone somewhere back in the mists of time as
a time that the system is likely to be quiet. The daily tasks still run on
the days the weekly tasks are scheduled, so some time displacement is
factored in to give the daily job time to finish. Likewise with the monthly
allowing for both the daily and weekly.

If any of the times are inappropriate for your system, you're at liberty to
change them to something more suitable.

Cheers,
Tom

-- 
I am not now, nor have I ever been, a member of the demigodic party.
		-- Dennis Ritchie

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

#256830

Tom Furie wrote: 
> On Fri, Apr 07, 2023 at 08:05:18AM +0800, ken@openmbox.net wrote:
> > Are the time format in /etc/crontab just random? why they are 6:25, 6:47
> > etc?
> 
> They aren't *random*, though they are somewhat arbitrary. The daily tasks
> run at 6:25, a time chosen by someone somewhere back in the mists of time as
> a time that the system is likely to be quiet. The daily tasks still run on
> the days the weekly tasks are scheduled, so some time displacement is
> factored in to give the daily job time to finish. Likewise with the monthly
> allowing for both the daily and weekly.

It's also the case that if you have a dozen, hundred or ten
thousand machines, you might not want them all doing the same
thing at precisely the same time -- especially if it's disk,
power or network intensive.

So spreading out jobs is often a good idea. Automated deployment
systems usually come with a way of randomizing the initial
install of a cronjob.


-dsr-

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web