Re: questions about cron.daily
On 09/04/2023 14:54, Michel Verdier wrote: Le 8 avril 2023 Max Nikulin a écrit : There is ready to use one: /usr/lib/systemd/user/emacs.service Perhaps there is no such file in buster. /usr/lib/systemd/user is for global system running. If you want to change something in the service you copy it in ~/.config/systemd to supersede global one. For minor tuning (adding new parameters or overwriting specific ones) it is possible to create a drop-in file, e.g. ~/.config/systemd/user/emacs.service.d/override.conf (or in /etc for all users). systemctl --user edit emacs.service See systemd.unit(5). Examples are usually given for system, not user units: - https://wiki.debian.org/systemd#Creating_or_altering_services - https://wiki.archlinux.org/title/systemd#Editing_provided_units - https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_basic_system_settings/assembly_working-with-systemd-unit-files_configuring-basic-system-settings#proc_extending-the-default-unit-configuration_assembly_working-with-systemd-unit-files
Re: questions about cron.daily
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.
Re: questions about cron.daily
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.
Re: questions about cron.daily
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.
Re: questions about cron.daily
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.
Re: questions about cron.daily
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
Re: questions about cron.daily
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.
Re: questions about cron.daily
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 !
Re: questions about cron.daily
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/. 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.
Re: questions about cron.daily
Le 8 avril 2023 Max Nikulin a écrit : > On 08/04/2023 22:17, Kushal Kumaran wrote: >>> Have you ever actually *made* a systemd --user unit file? If so, for >>> what purpose? >> I have one. It starts emacs server for me when I login. > > There is ready to use one: /usr/lib/systemd/user/emacs.service Perhaps there > is no such file in buster. /usr/lib/systemd/user is for global system running. If you want to change something in the service you copy it in ~/.config/systemd to supersede global one.
Re: questions about cron.daily
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
Re: questions about cron.daily
On 08/04/2023 22:17, Kushal Kumaran wrote: Have you ever actually *made* a systemd --user unit file? If so, for what purpose? I have one. It starts emacs server for me when I login. There is ready to use one: /usr/lib/systemd/user/emacs.service Perhaps there is no such file in buster.
Re: questions about cron.daily
On Sat, Apr 08 2023 at 08:39:14 AM, Greg Wooledge wrote: > On Sat, Apr 08, 2023 at 11:16:51AM +0200, Michel Verdier wrote: >> Le 8 avril 2023 Andrew M. A. Cater a écrit : >> >> > Likewise for creating systemd unit files - NEVER "just start editing over >> > the top" always have an example to work from and save it. You can then >> > commit the series to git if you want to record exact changes. >> >> 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? I have one. It starts emacs server for me when I login. -- regards, kushal
Re: questions about cron.daily
On 08/04/2023 19:39, Greg Wooledge wrote: Have you ever actually *made* a systemd --user unit file? If so, for what purpose? For LXC unprivileged containers that are stopped on logout. Do you mean it is exceptional case when default user units need adjustment? /usr/lib/systemd/user directory has enough entries when a desktop environment is installed. Even emacs server may be started as a systemd service.
Re: questions about cron.daily
On Sat, Apr 08, 2023 at 11:16:51AM +0200, Michel Verdier wrote: > Le 8 avril 2023 Andrew M. A. Cater a écrit : > > > Likewise for creating systemd unit files - NEVER "just start editing over > > the top" always have an example to work from and save it. You can then > > commit the series to git if you want to record exact changes. > > 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?
Re: questions about cron.daily
Le 8 avril 2023 Andrew M. A. Cater a écrit : > Likewise for creating systemd unit files - NEVER "just start editing over > the top" always have an example to work from and save it. You can then > commit the series to git if you want to record exact changes. systemd user files can be put in ~/.config/systemd/user/ where you can use git directly
Re: questions about cron.daily
On Sat, Apr 08, 2023 at 11:45:50AM +1200, Alex King wrote: > See man crontab. > > There are 2 ways of maintaining your crontab: > > crontab [ -u user ] file > ... > The first form of this command is used to install a new crontab from some > named file > > I.e. you can keep a file in your home directory (or anywhere,) update it and > install it when changed using "crontab filename". This is especially useful > if you keep your home directory under version control and want your crontab > under version control as well. But I guess hardly anyone does this. > This is *exactly* what I do when I'm editing crontabs, especially on a remote machine. crontab -l lists any crontabs for that user. crontab -l > crontab.old gives you a version of the crontab that you can keep. cp crontab.old crontab.new ; vi crontab.new ; diff crontab.old crontab.new will allow you to add new lines / change times or whatever. crontab crontab.new will put the new crontab in - but you've already got the old one if you need to revert changes. If you want to be fancy, you can do crontab. and have them sorted. Likewise for creating systemd unit files - NEVER "just start editing over the top" always have an example to work from and save it. You can then commit the series to git if you want to record exact changes. > > I believe it actually causes the current crontab to be copied to a temporary > file, where is edited, then it is installed after a successful editing > session and the temporary file is deleted. > Yes, > Like others, I've hardly ever met people who do things the first way, but it > likely was the original way of doing things. > > Thanks, > Alex > > All the very best, as ever, Andy
Re: questions about cron.daily
See man crontab.
There are 2 ways of maintaining your crontab:
crontab [ -u user ] file
...
The first form of this command is used to install a new crontab from
some named file
I.e. you can keep a file in your home directory (or anywhere,) update it
and install it when changed using "crontab filename". This is
especially useful if you keep your home directory under version control
and want your crontab under version control as well. But I guess hardly
anyone does this.
The second way:
crontab [ -u user ] [ -i ] { -e | -l | -r }
...
The -e option is used to edit the current crontab using the editor
specified by the VISUAL or EDITOR environment variables. After you
exit from the editor, the modified crontab will be installed automati‐
cally.
I believe it actually causes the current crontab to be copied to a
temporary file, where is edited, then it is installed after a successful
editing session and the temporary file is deleted.
Like others, I've hardly ever met people who do things the first way,
but it likely was the original way of doing things.
Thanks,
Alex
On 7/04/23 17:08, to...@tuxteam.de wrote:
On Thu, Apr 06, 2023 at 06:54:31PM -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.
It's news to me, too. I olny knew about the /var/spool/cron/crontabs
location.
Cheers
Re: questions about cron.daily
On 4/7/23, Anssi Saari wrote: > Greg Wooledge 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 *
Re: questions about cron.daily
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
Re: questions about cron.daily
Greg Wooledge 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.
Re: questions about cron.daily
On Thu, Apr 06, 2023 at 06:54:31PM -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. It's news to me, too. I olny knew about the /var/spool/cron/crontabs location. Cheers -- t signature.asc Description: PGP signature
Re: questions about cron.daily
Tom Furie wrote: > On Fri, Apr 07, 2023 at 08:05:18AM +0800, k...@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-
Re: questions about cron.daily
On Fri, Apr 07, 2023 at 08:05:18AM +0800, k...@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 signature.asc Description: PGP signature
Re: questions about cron.daily
On 2023-04-07 05:20, davidson wrote: 25 6* * * roottest -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/
Re: questions about cron.daily
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... > They then have to be installed > with crontab, which copies them into /var/spool/cron/crontabs/. ... which lives there.
Re: questions about cron.daily
On Thu 06 Apr 2023 at 12:28:05 (-0700), Fred wrote: > On 4/6/23 09:44, Pierre Frenkiel wrote: > > > > crontab -l > > > > On Thu, 6 Apr 2023, 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. > > fred@ragnok:~$ crontab -l > no crontab for fred > > root@ragnok:/home/fred# crontab -l > no crontab for root Users (including root) write their crontabs anywhere they like, typically in a directory like ~/.cron/. They then have to be installed with crontab, which copies them into /var/spool/cron/crontabs/. Those are the files that crontab -l lists. Why? Because cron isn't going to poke around in your home directory looking for a crontab there. It wants them somewhere it has control over. The system crontab is different, and is found in /etc/. It is an active file, and doesn't require any installing. It also has to contain an extra field: the user under which each item should be run—usually, but not always, root. Other parts of the system can also have their own crontabs, with similar properties, which are found in /etc/cron.d/. Cheers, David.
Re: questions about cron.daily
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* * * roottest -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
Re: questions about cron.daily
On 4/6/23 09:44, Pierre Frenkiel wrote: crontab -l Pierre Frenkiel On Thu, 6 Apr 2023, Fred wrote: On 4/6/23 08:33, Andy Smith wrote: Hello, On Thu, Apr 06, 2023 at 07:33:26PM +0800, cor...@free.fr wrote: For scripts put under /etc/cron.daily, which special time will they be implemented? Greg already showed you how to check this on your own systems. If you need something to run daily but at a specific time, consider instead either creating a custom cron job in /etc/cron.d/ (or a user's crontab) or else using a systemd timer. I found some services like apache2, chkrootkit will put the scripts in this dir automatically. are they for system cleaning purpose? The purpose of cron.daily is literally to run scripts daily for *whatever purpose each script has*. If you have questions about what a specific script does, try looking at it, as it's just an executable script (usually sh or bash). If you're still confused then ask a specific question about a specific script. Cheers, Andy 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. Best regards, Fred fred@ragnok:~$ crontab -l no crontab for fred root@ragnok:/home/fred# crontab -l no crontab for root best regards, Fred
Re: questions about cron.daily
On Thu, 2023-04-06 at 19:05 +0200, Thomas Schmitt wrote:
> Hi,
>
>
> Pierre Frenkiel wrote:
> > crontab -l
>
> Plus:
> man 5 crontab
> which has in its section "EXAMPLE CRON FILE"
>
> # run five minutes after midnight, every day
> 5 0 * * * $HOME/bin/daily.job >> $HOME/tmp/out 2>&1
>
> and explains further up
>
> The format of a cron command is very much the V7 standard,
> with a num‐
> ber of upward-compatible extensions. Each line has five time
> and date
> fields, followed by a command, followed by a newline character
> ('\n').
> ...
> field allowed values
> - --
> minute 0-59
> hour 0-23
> day of month 1-31
> month 1-12 (or names, see below)
> day of week 0-7 (0 or 7 is Sun, or use names)
>
> So the command shown by Greg Wooledge runs at 6:25 am the comand
>
> test -x /usr/sbin/anacron || ( cd / && run-parts --report
> /etc/cron.daily )
>
> which runs the programs in /etc/cron.daily (by run-parts(8)) if not
> /usr/sbin/anacron exists and is executable.
>
https://crontab.guru has a very nice explaining also.
Re: questions about cron.daily
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.
Re: questions about cron.daily
> 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
Re: questions about cron.daily
Hi,
Greg Wooledge wrote:
> > > unicorn:~$ grep daily /etc/crontab
> > > 25 6* * * roottest -x /usr/sbin/anacron || ( cd / && run-parts
> > > --report /etc/cron.daily )
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.
Pierre Frenkiel wrote:
> crontab -l
Plus:
man 5 crontab
which has in its section "EXAMPLE CRON FILE"
# run five minutes after midnight, every day
5 0 * * * $HOME/bin/daily.job >> $HOME/tmp/out 2>&1
and explains further up
The format of a cron command is very much the V7 standard, with a num‐
ber of upward-compatible extensions. Each line has five time and date
fields, followed by a command, followed by a newline character ('\n').
...
field allowed values
- --
minute 0-59
hour 0-23
day of month 1-31
month 1-12 (or names, see below)
day of week0-7 (0 or 7 is Sun, or use names)
So the command shown by Greg Wooledge runs at 6:25 am the comand
test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
which runs the programs in /etc/cron.daily (by run-parts(8)) if not
/usr/sbin/anacron exists and is executable.
Have a nice day :)
Thomas
Re: questions about cron.daily
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* * * roottest -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
Re: questions about cron.daily
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. signature.asc Description: PGP signature
Re: questions about cron.daily
crontab -l Pierre Frenkiel On Thu, 6 Apr 2023, Fred wrote: On 4/6/23 08:33, Andy Smith wrote: Hello, On Thu, Apr 06, 2023 at 07:33:26PM +0800, cor...@free.fr wrote: For scripts put under /etc/cron.daily, which special time will they be implemented? Greg already showed you how to check this on your own systems. If you need something to run daily but at a specific time, consider instead either creating a custom cron job in /etc/cron.d/ (or a user's crontab) or else using a systemd timer. I found some services like apache2, chkrootkit will put the scripts in this dir automatically. are they for system cleaning purpose? The purpose of cron.daily is literally to run scripts daily for *whatever purpose each script has*. If you have questions about what a specific script does, try looking at it, as it's just an executable script (usually sh or bash). If you're still confused then ask a specific question about a specific script. Cheers, Andy 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. Best regards, Fred
Re: questions about cron.daily
On 4/6/23 08:33, Andy Smith wrote: Hello, On Thu, Apr 06, 2023 at 07:33:26PM +0800, cor...@free.fr wrote: For scripts put under /etc/cron.daily, which special time will they be implemented? Greg already showed you how to check this on your own systems. If you need something to run daily but at a specific time, consider instead either creating a custom cron job in /etc/cron.d/ (or a user's crontab) or else using a systemd timer. I found some services like apache2, chkrootkit will put the scripts in this dir automatically. are they for system cleaning purpose? The purpose of cron.daily is literally to run scripts daily for *whatever purpose each script has*. If you have questions about what a specific script does, try looking at it, as it's just an executable script (usually sh or bash). If you're still confused then ask a specific question about a specific script. Cheers, Andy 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. Best regards, Fred
Re: questions about cron.daily
Hello, On Thu, Apr 06, 2023 at 07:33:26PM +0800, cor...@free.fr wrote: > For scripts put under /etc/cron.daily, which special time will they be > implemented? Greg already showed you how to check this on your own systems. If you need something to run daily but at a specific time, consider instead either creating a custom cron job in /etc/cron.d/ (or a user's crontab) or else using a systemd timer. > I found some services like apache2, chkrootkit will put the scripts in > this dir automatically. are they for system cleaning purpose? The purpose of cron.daily is literally to run scripts daily for *whatever purpose each script has*. If you have questions about what a specific script does, try looking at it, as it's just an executable script (usually sh or bash). If you're still confused then ask a specific question about a specific script. Cheers, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting
Re: questions about cron.daily
On Thu, Apr 06, 2023 at 07:33:26PM +0800, cor...@free.fr wrote: > For scripts put under /etc/cron.daily, which special time will they be > implemented? unicorn:~$ grep daily /etc/crontab 25 6* * * roottest -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
questions about cron.daily
Hello list, For scripts put under /etc/cron.daily, which special time will they be implemented? I know they will be run daily, but not sure about the special run time. And, I found some services like apache2, chkrootkit will put the scripts in this dir automatically. are they for system cleaning purpose? Thanks. Corey
