On Mon, 2024-09-16 at 17:40 +0100, Barry wrote:
>
> > On 16 Sep 2024, at 10:48, Patrick O'Callaghan wrote:
> >
> > I suspect the real problem is that the cron line is running as root,
> > but Apache wants to run as the apache user. I'll try using 'cront
On Mon, Sep 16, 2024 at 12:41 PM Barry wrote:
>
> > On 16 Sep 2024, at 10:48, Patrick O'Callaghan wrote:
> >
> > I suspect the real problem is that the cron line is running as root,
> > but Apache wants to run as the apache user. I'll try using 'cront
> On 16 Sep 2024, at 10:48, Patrick O'Callaghan wrote:
>
> I suspect the real problem is that the cron line is running as root,
> but Apache wants to run as the apache user. I'll try using 'crontab -u
> apache ...' to see if that makes any difference.
You
t; PATH=/usr/bin:/bin:/usr/sbin:/sbin
> _=/usr/bin/printenv
>
> There's nothing there that should affect SElinux.
Looks like I was wrong. Using the shell script still produces the AVC,
which for some reason I hadn't spotted. At least it's consistent.
I suspect the real pr
On Thu, 2024-09-12 at 12:14 +0930, Tim via users wrote:
> On Wed, 2024-09-11 at 12:19 +0100, Patrick O'Callaghan wrote:
> > Turns out I don't need any of this. If I substitute my original crontab
> > line for one that simply calls a Shell script which in turn calls
> > apachectl, then it all works
On Wed, 2024-09-11 at 12:19 +0100, Patrick O'Callaghan wrote:
> Turns out I don't need any of this. If I substitute my original crontab
> line for one that simply calls a Shell script which in turn calls
> apachectl, then it all works with no AVC.
ENVironment differences? The crontab versus your
On Tue, 2024-09-10 at 11:55 -0500, Thomas Cameron wrote:
> On 9/10/24 5:30 AM, Patrick O'Callaghan wrote:
> > I have a cron line that attempts to restart httpd every morning, but
> > it's failing with an AVC error:
> >
> > Sep 10 08:00:00 Bree CROND[723189
On 9/10/24 5:30 AM, Patrick O'Callaghan wrote:
I have a cron line that attempts to restart httpd every morning, but
it's failing with an AVC error:
Sep 10 08:00:00 Bree CROND[723189]: (root) CMD ((echo "$(date): Apache: calling restart")
>> /var/log/httpd/my-log &
On Tue, 2024-09-10 at 13:45 +0100, Barry wrote:
>
> > On 10 Sep 2024, at 11:31, Patrick O'Callaghan wrote:
> >
> > I have a cron line that attempts to restart httpd every morning, but
> > it's failing with an AVC error:
> >
> > Sep 10 08:00
> On 10 Sep 2024, at 11:31, Patrick O'Callaghan wrote:
>
> I have a cron line that attempts to restart httpd every morning, but
> it's failing with an AVC error:
>
> Sep 10 08:00:00 Bree CROND[723189]: (root) CMD ((echo "$(date): Apache:
> calling restar
I have a cron line that attempts to restart httpd every morning, but
it's failing with an AVC error:
Sep 10 08:00:00 Bree CROND[723189]: (root) CMD ((echo "$(date): Apache: calling
restart") >> /var/log/httpd/my-log && /usr/sbin/apachectl restart)
Sep 10 08:00:00
r contains:-
> espeak -a15 -p25 -s160 "Hey, get Joe a drink of water"
> zenity --info --title "Joe and water drinking" --width=850 --height=250
> --text "drink"
>
> This works in a terminal with ./Joe-drink-water-reminder (including doing the
> zenity
Joe-drink-water-reminder contains:-
> espeak -a15 -p25 -s160 "Hey, get Joe a drink of water"
> zenity --info --title "Joe and water drinking" --width=850 --height=250
> --text "drink"
>
> This works in a terminal with ./Joe-drink-water-reminder (including
title "Joe and water drinking" --width=850 --height=250
--text "drink"
This works in a terminal with ./Joe-drink-water-reminder (including doing
the zenity command), BUT not when cron initiates it (it only does the
espeak bit).
This worked fine in f37 and earlier, just not f38.
A
> On 22 Mar 2023, at 04:50, Ranjan Maitra wrote:
>
> Thanks, so no cron job? And, my apologies, but where can I get an example?
Here is an example that I use:
$ systemctl --user cat mail-maintenance.timer
# /home/barry-mail/.config/systemd/user/mail-maintenance.timer
[Unit]
Descrip
On Tue Mar21'23 10:47:47PM, Barry wrote:
> From: Barry
> Date: Tue, 21 Mar 2023 22:47:47 +
> To: Community support for Fedora users
> Reply-To: Community support for Fedora users
> Subject: Re: OT: is it possible to have one cron job follow GMT/UTC?
>
>
>
k does not quite work. (I
>> am aware that I could set my cron job to be at a specific hour later than
>> the actual during standard time, but I figured that this would be a good
>> opportunity to get to know of such a possibility, if such exists.)
>> So, how do I make a
On 3/19/23 21:19, Ranjan Maitra wrote:
So, how do I make a single entry that uses GMT or UTC, in my crontab? While
also using the local time for the other tasks on crontab?
Create a file in /etc/cron.d and put "CRON_TZ=UTC" in it.
___
users mailing
a clock that does not spring forward and fall back. This
is because these maps appear to be released according to GMT/UTC and so setting
the time according to the local clock does not quite work. (I am aware that I
could set my cron job to be at a specific hour later than the actual during
fall back. This
is because these maps appear to be released according to GMT/UTC and so setting
the time according to the local clock does not quite work. (I am aware that I
could set my cron job to be at a specific hour later than the actual during
standard time, but I figured that this would
fine when running as a regular user, from the command shell/zsh.
- Script fails with "permission denied" when running from the same user's cron
or from a systemd user timer, when attempting a system("rm -rf "), or
alternatively using Find::File's rmtree, on several expli
On Thu, 25 Mar 2021 08:58:20 -0500
SternData wrote:
> In F33's logwatch, I'm seeing a CRON block full of lines like this:
>
> This seems to be new.
Yep, new:
https://bugzilla.redhat.com/show_bug.cgi?id=1941630
___
users ma
In F33's logwatch, I'm seeing a CRON block full of lines like this:
This seems to be new. Or, at least, I can't tie it to anything I've
done diffrently
----- Cron Begin
**Unmatched Entries**
CMDEND (run-parts /etc/cron.
backups have failed to run due the following errors:
Oct 1 11:10:01 terrapin CROND[110219]: (root) CMD
(/usr/local/bro/bin/zeekctl cron)
Oct 1 11:12:01 terrapin crond[1565]: ((null)) No SELinux security context
(/etc/crontab)
Oct 1 11:12:01 terrapin crond[1565]: (root) FAILED (loading cron table
On Thu, Oct 01, 2020 at 11:53:00AM -0700, Paolo Galtieri wrote:
>
> Folks,
> since August 13 my backups have failed to run due the following errors:
>
> Oct 1 11:10:01 terrapin CROND[110219]: (root) CMD
> (/usr/local/bro/bin/zeekctl cron)
> Oct 1 11:12:01 terrapin cro
Folks,
since August 13 my backups have failed to run due the following errors:
Oct 1 11:10:01 terrapin CROND[110219]: (root) CMD
(/usr/local/bro/bin/zeekctl cron)
Oct 1 11:12:01 terrapin crond[1565]: ((null)) No SELinux security
context (/etc/crontab)
Oct 1 11:12:01 terrapin crond[1565
On Fri, 31 Jul 2020 05:51:21 +0800
Ed Greshko wrote:
> Well, it seems similar issues have come up in the past.
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1309108
>
> and
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1298192
>
> You may want to try the work around in comment 19 of that
On 2020-07-31 01:25, stan via users wrote:
> On Thu, 30 Jul 2020 05:09:30 +0800
> Ed Greshko wrote:
>
>> Have you considered doing a relabel?
>>
>> fixfiles -F onboot
>>
>> and reboot?
> I tried a touch /.autorelabel and reboot but it followed symbolic links,
> and I have a bunch of links in /home
On Thu, 30 Jul 2020 05:09:30 +0800
Ed Greshko wrote:
> Have you considered doing a relabel?
>
> fixfiles -F onboot
>
> and reboot?
I tried a touch /.autorelabel and reboot but it followed symbolic links,
and I have a bunch of links in /home and /mnt. So I stopped it. It
looks like I can rest
On 2020-07-30 04:29, stan via users wrote:
> I reinstalled all the selinux components, and still the problem
> persists. I'm going to drop this for a while, see if anything comes to
> me. I have your workaround for the time being.
Have you considered doing a relabel?
fixfiles -F onboot
and reb
have dwatch
> installed? All of my F31 systems are running cron jobs just fine and
> they are all fully updated.
No, but I removed dwatch from /etc/cron.d, and the behavior persists.
I think I have something installed that you do not, though it is good
to see that your system
be able to tell if the hourly cron job runs...
>>
>> journalctl -b 0 | grep hourly
>>
>> should return a bunch of stuff like...
>>
>> Jul 29 20:01:01 meimei.greshko.com CROND[29642]: (root) CMD
>> (run-parts /etc/cron.hourly) Jul 29 20:01:01 meimei.gresh
?packageID=4453
> Well, you should easily be able to tell if the hourly cron job runs...
>
> journalctl -b 0 | grep hourly
>
> should return a bunch of stuff like...
>
> Jul 29 20:01:01 meimei.greshko.com CROND[29642]: (root) CMD
> (run-parts /etc/cron.hourly) Jul 29
atch (Daemon Watch) is a program that watches over other programs and
> performs actions based on conditions specified in a configuration file.
> See dwatch.conf for an example of what the file might look like.
>
> Dwatch is meant to be run from cron at regular intervals.
So, dwatch is
Host : localhost
URL : http://siag.nu/dwatch/
Summary : A program that watches over other programs
Description :
Dwatch (Daemon Watch) is a program that watches over other programs and
performs actions based on conditions specified in a configuration file.
See dwatch.conf for an exampl
g.cgi?id=1861505
Could you clarify things a bit?
I still don't know what "daemon watch" is. What package/rpm supplies this?
Also, in the BZ you say "No cron jobs run" but in the thread it sounded to me
as if it was only
cron jobs associated with "dwatch". So, whic
On Tue, 28 Jul 2020 10:35:54 -0700
stan via users wrote:
> Before I open a bugzilla, I wanted to check if anyone has an
> explanation for this, and a fix.
Opened a bugzilla,
https://bugzilla.redhat.com/show_bug.cgi?id=1861505
___
users mailing list --
; What is "dwatch". I can't find any reference to it (other than BSD).
It's a shortcut for daemon watch. It checks whether a user daemon is
running, and if it isn't, starts it according to an invocation in a
conf file. I use it to run my entropy gathering daemons. None of
On 7/28/20 10:35 AM, stan via users wrote:
Recently, I've noticed that some jobs that are started by dwatch,
aren't starting. If I start them manually, they start fine. dwatch is
What is "dwatch". I can't find any reference to it (other than BSD).
On 7/28/20 10:35 AM, stan via users wrote:
Recently, I've noticed that some jobs that are started by dwatch,
aren't starting. If I start them manually, they start fine. dwatch is
in cron.d, and should be running every 5 minutes, but no cron jobs are
running. I see the following in
Recently, I've noticed that some jobs that are started by dwatch,
aren't starting. If I start them manually, they start fine. dwatch is
in cron.d, and should be running every 5 minutes, but no cron jobs are
running. I see the following in journalctl,
Jul 28 10:07:08 localhost.localdo
On Tue, 2020-06-23 at 19:17 -0500, Roger Heflin wrote:
> The uuid= I believe requires a link that udev creates when the device
> gets created and it scans it. That link may or may not be done when
> mdadm returns with 0 as that udev/link creating is not in the mdadm
> code path.
>
>
> So wait a
The uuid= I believe requires a link that udev creates when the device
gets created and it scans it. That link may or may not be done when
mdadm returns with 0 as that udev/link creating is not in the mdadm
code path.
So wait a second before you mount it. In reality it will probably
happen much f
On Tue, 2020-06-23 at 09:23 -0700, Doug H. wrote:
> > I'm assuming that once mdadm returns 0 the array is up and running.
>
>
> Perhaps a simpler way to assure that it is running is to check a static
> file that you place on the raid. If it is there then the raid is up. It
> would show the file
On Tue, 2020-06-23 at 09:23 -0700, Doug H. wrote:
> > I'm assuming that once mdadm returns 0 the array is up and running.
>
>
> Perhaps a simpler way to assure that it is running is to check a static
>
> file that you place on the raid. If it is there then the raid is up. It
>
> would show the
On Tue, 2020-06-23 at 17:07 +0100, Patrick O'Callaghan wrote:
> On Tue, 2020-06-23 at 06:12 -0500, Roger Heflin wrote:
> > How are you mounting the filesystem? (I don't remember details from
> >
> > the prior discussion) Directly with /dev/mdXXX or are you using
> > some
> > other link? If you a
On Tue, 2020-06-23 at 06:12 -0500, Roger Heflin wrote:
> How are you mounting the filesystem? (I don't remember details from
>
> the prior discussion) Directly with /dev/mdXXX or are you using some
> other link? If you are using some other link then udev needs time to
> get the original mdXXX cr
> > /usr/local/bin/dock down
> >
> > I would suggest to avoid multiple commands on a cron entry,
> > better to have a simple /usr/local/bin/do_backup with the three commands
> > inside.
> >
> > There you can log with "date" commands the execut
On Mon, 2020-06-22 at 18:35 +0200, Roberto Ragusa wrote:
> On 2020-06-21 18:54, Patrick O'Callaghan wrote:
> > 0 3 * * * root /usr/local/bin/dock up && /usr/bin/borgmatic ;
> > /usr/local/bin/dock down
>
> I would suggest to avoid multiple commands on a cron ent
On 2020-06-21 18:54, Patrick O'Callaghan wrote:
0 3 * * * root /usr/local/bin/dock up && /usr/bin/borgmatic ;
/usr/local/bin/dock down
I would suggest to avoid multiple commands on a cron entry,
better to have a simple /usr/local/bin/do_backup with the three commands inside.
On Sun, 2020-06-21 at 18:06 -0500, Roger Heflin wrote:
> It would appear that the md stop is still running when you remove the disk.
>
>
>
> So in both cases you run the exact same script but from cron it fails?
Yes.
> I would think you either need a loop validating that
It would appear that the md stop is still running when you remove the disk.
So in both cases you run the exact same script but from cron it fails?
I would think you either need a loop validating that the md stopped or
just put a simple few second sleep delay between the md stop and the
disk stop
I have a backup script (using Borgmatic) I run every night, where the
target is a RAID1 array connected by a USB dock. The dock is normally
off so the script turns it on, does the backup, then turns it off
again. This is the cron entry:
# cat /etc/cron.d/borgmatic
# Run borgmatic every day at
On Mon, 2020-05-11 at 08:48 -0400, Robert Moskowitz wrote:
> Yes. You are saying that it is ok for cron to be depended on an
> MTA. that no MDA is available that does this correctly. That "out
> of the box" cron is lessed on a workstation that really should not
> need an
I want to thank all of you for your help and forbearance.
The script is working to my satisfaction, though I still have to see
tonight if it again throws an selinux alert for the logwatch cron task.
Next I will probably be active over on the procmail list as I rewrite
this using formail and
On 5/11/20 8:41 AM, Ed Greshko wrote:
On 2020-05-11 20:33, Robert Moskowitz wrote:
The biggie is no DATE: header. And the MTA can only apply a DATE: header for
the time it received the cron output. The time the cron task started is lost.
This is a bug in cron from day 1, it seems and I
/archive/html/procmail/2014-01/msg0.html
I worked on cron outbut via procmail way back then and used:
CRONDARGS=-m "/usr/bin/procmail -f cron"
So I just tried this and I have one problem with it. No DATE header.
formail -i "Date: $(date +'%a, %e %b %Y %T %z (%Z)')&quo
On 2020-05-11 20:33, Robert Moskowitz wrote:
> The biggie is no DATE: header. And the MTA can only apply a DATE: header for
> the time it received the cron output. The time the cron task started is
> lost. This is a bug in cron from day 1, it seems and I will be submitting
>
On 5/11/20 8:14 AM, Tim via users wrote:
On Mon, 2020-05-11 at 17:43 +0800, Ed Greshko wrote:
I also think it is a good idea to see the format of what procmail is
getting from cron and comparing it to what ends up delivered by an
MTA such as postfix.
From egreshko . is missing along
On 2020-05-11 20:14, Tim via users wrote:
> On Mon, 2020-05-11 at 17:43 +0800, Ed Greshko wrote:
>> I also think it is a good idea to see the format of what procmail is
>> getting from cron and comparing it to what ends up delivered by an
>> MTA such as postfix.
>>
On Mon, 2020-05-11 at 17:43 +0800, Ed Greshko wrote:
> I also think it is a good idea to see the format of what procmail is
> getting from cron and comparing it to what ends up delivered by an
> MTA such as postfix.
>
> From egreshko . is missing along with
> Return-Pa
a message, and the email
> program *could* add a date to an undated message, or replace a pre-
> filled in date of authoring with the actual date of transmission.
>
> NB: I mean the full time and date, not just the date.
>
I also think it is a good idea to see the format of what procm
On Mon, 2020-05-11 at 16:59 +0800, Ed Greshko wrote:
> It is then the MTA, in my case postfix, which adds the additional
> headers.
I always thought they did that, anyway.
e.g. My mail client *could* send a date with a message, and the email
program *could* add a date to an undated message, or re
On 2020-05-11 15:45, Ed Greshko wrote:
>
> I'm also confused by the need to create headers before feeding anything to
> procmail since
> cron generate a fully formatted mail message as noted in the -m option.
>
OK, I cleared up my confusion on this one. I set -m of crond to
On 2020-05-11 15:34, Cameron Simpson wrote:
> On 11May2020 11:51, Ed Greshko wrote:
>> Just want to make sure you saw my response to your original post Subject:
>> user crontab?
>>
>> The MTA has to be running in order for mail from cron to be processed.
>
> Rob
On 11May2020 11:51, Ed Greshko wrote:
Just want to make sure you saw my response to your original post
Subject: user crontab?
The MTA has to be running in order for mail from cron to be processed.
Robert doesn't want to put an MTA in. It looks like the cron -m argument
lets you specif
onarc.org/archive/html/procmail/2014-01/msg0.html
>>
>> I worked on cron outbut via procmail way back then and used:
>>
>> CRONDARGS=-m "/usr/bin/procmail -f cron"
>>
>> So I just tried this and I have one problem with it. No DATE header.
>>
&
I almost have it...
On 5/10/20 7:03 PM, Robert Moskowitz wrote:
I have been digging for how to do today and found something interesting:
Back in Fedora 20, there was no MTA!
https://www.mhonarc.org/archive/html/procmail/2014-01/msg0.html
I worked on cron outbut via procmail way back then
I have been digging for how to do today and found something interesting:
Back in Fedora 20, there was no MTA!
https://www.mhonarc.org/archive/html/procmail/2014-01/msg0.html
I worked on cron outbut via procmail way back then and used:
CRONDARGS=-m "/usr/bin/procmail -f cron"
On Fri, 2020-05-08 at 08:23 -0400, Robert Moskowitz wrote:
> This is a little more challenging when you don't have a mailer.
If you don't want to run a mail server, you could do a different
approach: Have a watchdog program monitor a /var/log/your-log-file and
act upon it.
--
uname -rsvp
Lin
how they were:
> systemctl stop logwatch
This is probably not necessary since this "service" is of type oneshot
and has thus surely already finished.
> And then wait until cron.daily
Yes.
Another weakness of cron compared to systemd.timer :-):
you cannot test your change imm
atch"
was for logwatch to send its output to /var/log/messages
So what am I missing?
The logwatch RPM allows 2 ways to launch logwatch:
- with cron /etc/cron.daily/0logwatch
- with a systemd timer /usr/lib/systemd/system/logwatch.{service,timer}
By using 'systemctl res
art logwatch"
> was for logwatch to send its output to /var/log/messages
> So what am I missing?
The logwatch RPM allows 2 ways to launch logwatch:
- with cron /etc/cron.daily/0logwatch
- with a systemd timer /usr/lib/systemd/system/logwatch.{service,timer}
By using &
/mycron"
And see what happens next.
# cat /etc/logwatch/conf/logwatch.conf
# Local configuration options go here (defaults are in
/usr/share/logwatch/default.conf/logwatch.conf)
mailer = "/usr/local/mycron"
# cat /usr/local/mycron
#!/bin/sh
currentDate="$(date +'%a %b
This is a little more challenging when you don't have a mailer. I see
it ran:
May 8 03:01:02 lx140e anacron[66134]: Anacron started on 2020-05-08
May 8 03:01:02 lx140e anacron[66134]: Will run job `cron.daily' in 26 min.
May 8 03:01:02 lx140e anacron[66134]: Jobs will be executed sequentiall
tpics-vis)
Apr 09 19:00:01 meimei.greshko.com CROND[76411]: (egreshko) CMD
(/home/egreshko/bin/getpics-vis2)
Are you getting 2 starts of the same script recorded?
No, the cron log in /var/log/cron only shows one for the backup log below:
Bbackup 805476 / /usr/beam /home /src /srcOld /dist
On 2020-04-09 17:57, Terry Barnaby wrote:
> The script already has date/time and the log shows (The Wed 8th entries entry
> having the PID):
>
> Bbackup / /usr/beam /home /src /srcOld /dist /opt /scratch /data/svn
> /data/www /data/vwt /data/www /data1/kvm /data/database /data/vwt
> /data/backup
/src/bbackup/bbackup-beam
01 23 * * 4 root /src/bbackup/bbackup-beam
01 23 * * 5 root /src/bbackup/bbackup-beam
This system has been in use for 10 years or more on various Fedora
versions. However about 18 months ago I have seen a problem where cron
will start two backups with identical start times
something silly and obvious in what I am doing.
I will have a more detailed look at the system and my backup shell
script and create a simple test cron job to see if it shows the same
thing ...
How about sticking:
echo "`date` [`date -u`]: start $0 $*" >>some_log_file
at the start
; 01 23 * * 4 root /src/bbackup/bbackup-beam
> 01 23 * * 5 root /src/bbackup/bbackup-beam
> This system has been in use for 10 years or more on various Fedora
> versions. However about 18 months ago I have seen a problem where cron
> will start two backups with identical start times o
will have a more detailed look at the system and my backup shell
script and create a simple test cron job to see if it shows the same
thing ...
How about sticking:
echo "`date` [`date -u`]: start $0 $*" >>some_log_file
at the start. Makes sure the job is actually starting
On 08Apr2020 07:52, Ed Greshko wrote:
On 2020-04-08 07:27, Cameron Simpson wrote:
On 07Apr2020 07:07, Terry Barnaby wrote:
01 23 * * 1 root /src/bbackup/bbackup-beam
[...]
1:23am. Do not the timezone shifts happen at 2am (avoids horrible day changes
if it happened at 12am). So 1:23am can h
On 04/08/2020 06:21 AM, Patrick O'Callaghan wrote:
I don't know how it works where you live, but in the UK the autumn
switch occurs at 2am, which reverts back to being 1am. Thus a time such
as 1:30am occurs twice, and events programmed for that time can be
triggered twice.
It's the same in the
ds.
> Yes, that's clear. I was simply answering the general question (since
> you said "to/from DST"), even though it doesn't apparently affect cron
> as such, as documented in the manual.
>
OK then.
--
The key to getting good answers is to ask good questions.
;to/from DST"), even though it doesn't apparently affect cron
as such, as documented in the manual.
poc
___
Note this has happened a few times this year, (approx 1 in 64 x) so not
related to DST changes anyway. Might be due to chrony clock
nce
you said "to/from DST"), even though it doesn't apparently affect cron
as such, as documented in the manual.
poc
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
. Thus a time such
> as 1:30am occurs twice, and events programmed for that time can be
> triggered twice.
>
BUT, we are specifically addressing the OP's situation and the time in his
crontab ISN'T within the
time frame of when BST (the OP is in the UK) starts/ends.
Daylight
On Wed, 2020-04-08 at 20:11 +0800, Ed Greshko wrote:
>If time was adjusted one hour forward, those jobs that would have run
> in
>the interval that has been skipped will be run immediately.
> Conversely,
>if time was adjusted backward, running the same job twice is avoide
On Wed, 2020-04-08 at 17:06 +0800, Ed Greshko wrote:
> On 2020-04-08 16:56, Patrick O'Callaghan wrote:
> > On Wed, 2020-04-08 at 07:52 +0800, Ed Greshko wrote:
> > > On 2020-04-08 07:27, Cameron Simpson wrote:
> > > > On 07Apr2020 07:07, Terry Barnaby wrote:
> > > > > 01 23 * * 1 root /src/bbackup
On 2020-04-08 20:01, Andy Paterson via users wrote:
> I understood crontab used UTC time - daylight saving shouldn't apply
>
Not unless you set the CRON_TZ variable.
Also, if that were the case then the man page wouldn't need to tell you
Daylight Saving Time and other time changes
I understood crontab used UTC time - daylight saving shouldn't apply
> On 8 Apr 2020, at 10:07, Ed Greshko wrote:
>
> On 2020-04-08 16:56, Patrick O'Callaghan wrote:
>>> On Wed, 2020-04-08 at 07:52 +0800, Ed Greshko wrote:
>>> On 2020-04-08 07:27, Cameron Simpson wrote:
On 07Apr2020 07:07,
On 2020-04-08 16:56, Patrick O'Callaghan wrote:
> On Wed, 2020-04-08 at 07:52 +0800, Ed Greshko wrote:
>> On 2020-04-08 07:27, Cameron Simpson wrote:
>>> On 07Apr2020 07:07, Terry Barnaby wrote:
01 23 * * 1 root /src/bbackup/bbackup-beam
>>> [...]
>>>
>>> 1:23am. Do not the timezone shifts ha
On Wed, 2020-04-08 at 07:52 +0800, Ed Greshko wrote:
> On 2020-04-08 07:27, Cameron Simpson wrote:
> > On 07Apr2020 07:07, Terry Barnaby wrote:
> > > 01 23 * * 1 root /src/bbackup/bbackup-beam
> > [...]
> >
> > 1:23am. Do not the timezone shifts happen at 2am (avoids horrible day
> > changes if
On 2020-04-08 07:27, Cameron Simpson wrote:
> On 07Apr2020 07:07, Terry Barnaby wrote:
>> 01 23 * * 1 root /src/bbackup/bbackup-beam
> [...]
>
> 1:23am. Do not the timezone shifts happen at 2am (avoids horrible day changes
> if it happened at 12am). So 1:23am can happen twice if 2am steps back to
On 07Apr2020 07:07, Terry Barnaby wrote:
01 23 * * 1 root /src/bbackup/bbackup-beam
[...]
1:23am. Do not the timezone shifts happen at 2am (avoids horrible day
changes if it happened at 12am). So 1:23am can happen twice if 2am steps
back to 1am.
Our summer time just ended here. Might a sim
On 4/7/20 3:21 AM, Terry Barnaby wrote:
On 07/04/2020 09:03, Samuel Sieb wrote:
On 4/6/20 11:07 PM, Terry Barnaby wrote:
This system has been in use for 10 years or more on various Fedora
versions. However about 18 months ago I have seen a problem where
cron will start two backups with
On 07/04/2020 13:06, Iosif Fettich wrote:
Hi Terry,
Yes, there is nothing unusual in /var/log/cron:
Apr 6 22:01:01 beam CROND[651585]: (root) CMD (run-parts
/etc/cron.hourly)
[...]
/var/log/messages
Feb 24 23:00:03 beam dhcpd[1743]: DHCPREQUEST for 192.168.201.214
from 00:25:b3:e6:a9
Hi Terry,
Yes, there is nothing unusual in /var/log/cron:
Apr 6 22:01:01 beam CROND[651585]: (root) CMD (run-parts /etc/cron.hourly)
[...]
/var/log/messages
Feb 24 23:00:03 beam dhcpd[1743]: DHCPREQUEST for 192.168.201.214 from
00:25:b3:e6:a9:18 via enp4s0
[...]
In the backup log
Hi Terry,
The bbackup-beam shell script is pretty basic and I can't see how this could
have an issue like this.
Googling on similar issues finds some hits where the cause were two
running cron daemons, e.g.
https://stackoverflow.com/questions/1004764/why-is-this-cron-entry-executed-
Hi Terry,
I have assumed the system time is always UTC synchronised using chronyd. The
servers user code is running under the GMT timezone. I was wondering if the
tweaking of the time by chronyd could cause this issue, but I would have
thought this situation would have been handled by crond
1 - 100 of 342 matches
Mail list logo
