Re: fedora 38 cron zenity
On Jul 19, 2023, at 09:18, Joe Feely via users wrote: > I have a few little scripts that crontab runs. Well it runs the espeak > commands but no sign of it running the zenity bits > > In crontab:- > 0 * * * * ./Joe-drink-water-reminder > > File 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 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. > Any pointers (I've "googled" it with no success) Tasks running in cron are running in a completely different session than your graphical login session, so they can’t launch graphical processes (although you can sometimes set the righ environment variables to trick it). Audio that interacts directly with the sound device will likely work because the user is granted access to the device. I think pipewire and pulseaudio have a socket that is well known so that should work too. You might get a better result by running them in a systemd --user timer unit, which I believe will run in your login session. -- Jonathan Billings ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: fedora 38 cron zenity
> On 19 Jul 2023, at 14:18, Joe Feely via users > wrote: > > > I have a few little scripts that crontab runs. Well it runs the espeak > commands but no sign of it running the zenity bits > > In crontab:- > 0 * * * * ./Joe-drink-water-reminder > > File 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 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. > Any pointers (I've "googled" it with no success) In cron the process does not have the DISPLAY or DISPLAY_WAYLAND env var set so you cannot open a gui window I expect? I an a little surprised that sound worked from cron. Barry > > Thanks, > Joe > ___ > users mailing list -- users@lists.fedoraproject.org > To unsubscribe send an email to users-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
fedora 38 cron zenity
I have a few little scripts that crontab runs. Well it runs the espeak commands but no sign of it running the zenity bits In crontab:- 0 * * * * ./Joe-drink-water-reminder File 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 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. Any pointers (I've "googled" it with no success) Thanks, Joe ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: OT: is it possible to have one cron job follow GMT/UTC?
> 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] Description=mail maintenance [Timer] OnCalendar=02:45 #OnCalendar=14:45 $ systemctl --user cat mail-maintenance.service # /home/barry-mail/.config/systemd/user/mail-maintenance.service [Unit] Description=mail maintenance [Service] Type=oneshot # use a shared lock while do the main actions # which include stopping dovecot etc. ExecStart=flock -s /usr/lib/systemd/system/dovecot.service %h/fetchmail/mail-maintenance.sh maintenance # use a exclusive lock to make sure that there are no other main-maintenance # services running in maintenance mode before turning dovecot back on ExecStartPost=flock -x /usr/lib/systemd/system/dovecot.service %h/fetchmail/mail-maintenance.sh post_dovecot ExecStartPost=%h/fetchmail/mail-maintenance.sh post_fetchmail The OnCalendar can have a timezone on it like this: OnCalendar=02:45 UTC man systemd.time details the format accepted. Barry ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: OT: is it possible to have one cron job follow GMT/UTC?
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? > > > > > On 21 Mar 2023, at 08:52, Mike Wright wrote: > > > > On 3/19/23 21:19, Ranjan Maitra wrote: > >> Dear friends, > >> I have a bunch of entries in my crontab, all doing different things at > >> different times. These times are picked up by the computer clock. > >> However, one particular task (downloading weather maps) would benefit if > >> it was set to download using 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 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 single entry that uses GMT or UTC, in my crontab? > >> While also using the local time for the other tasks on crontab? > > > > That sounds ideal for a systemd timer since it has native support > > for UTC. You'd need a .service to fetch the weather maps and a > > .timer to trigger the .service. As far as systemd goes that is > > pretty basic. Thanks, so no cron job? And, my apologies, but where can I get an example? > > Yep defaults to UTC but allows you to specify the time zone in the OnCalendar > property. This is very useful. > > Barry > > > > Everything else would stay under cron. > > > > Mike Wright Thanks again! Ranjan ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: OT: is it possible to have one cron job follow GMT/UTC?
> On 21 Mar 2023, at 08:52, Mike Wright wrote: > > On 3/19/23 21:19, Ranjan Maitra wrote: >> Dear friends, >> I have a bunch of entries in my crontab, all doing different things at >> different times. These times are picked up by the computer clock. >> However, one particular task (downloading weather maps) would benefit if it >> was set to download using 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 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 single entry that uses GMT or UTC, in my crontab? While >> also using the local time for the other tasks on crontab? > > That sounds ideal for a systemd timer since it has native support for UTC. > You'd need a .service to fetch the weather maps and a .timer to trigger the > .service. As far as systemd goes that is pretty basic. Yep defaults to UTC but allows you to specify the time zone in the OnCalendar property. This is very useful. Barry > > Everything else would stay under cron. > > Mike Wright > ___ > users mailing list -- users@lists.fedoraproject.org > To unsubscribe send an email to users-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: OT: is it possible to have one cron job follow GMT/UTC?
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 list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: OT: is it possible to have one cron job follow GMT/UTC?
On 3/19/23 21:19, Ranjan Maitra wrote: Dear friends, I have a bunch of entries in my crontab, all doing different things at different times. These times are picked up by the computer clock. However, one particular task (downloading weather maps) would benefit if it was set to download using 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 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 single entry that uses GMT or UTC, in my crontab? While also using the local time for the other tasks on crontab? That sounds ideal for a systemd timer since it has native support for UTC. You'd need a .service to fetch the weather maps and a .timer to trigger the .service. As far as systemd goes that is pretty basic. Everything else would stay under cron. Mike Wright ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
OT: is it possible to have one cron job follow GMT/UTC?
Dear friends, I have a bunch of entries in my crontab, all doing different things at different times. These times are picked up by the computer clock. However, one particular task (downloading weather maps) would benefit if it was set to download using 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 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 single entry that uses GMT or UTC, in my crontab? While also using the local time for the other tasks on crontab? Many thanks and best wishes, Ranjan ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
cifs (autofs) access denied to script when running from cron or systemd timer
Perl script deletes/recreates an hierarchy over SMB via an autofs mount point
using CIFS.
Credentials used in the autofs map are for a generic shared user with a
password that doesn't need to be changed periodically.
On a Fedora 34 system nightly updated (except kernel),
- Script works 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 explicit full
/mount/point/path/to/file, thus it is trying to do the rm and there isn't a
problem with paths when running the script from cron/systemd.
On a RHEL7 system, only updated with CentOS or EPEL packages where needed, it
works both from the command line or cron (didn't try systemd).
What extra permissions/configuration are needed to make it work on Fedora 34??
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: Cron errors(?) in logwatch
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 mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Cron errors(?) in logwatch
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.hourly) -- -- Steve ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: (root) FAILED (loading cron table)
Yes that looks like the same problem. I did an update yesterday and there was no selinux update, but there was one today. This fixed my problem. Paolo On 10/1/20 12:56 PM, Jonathan Billings wrote: 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 crond[1565]: ((null)) No SELinux security context (/etc/crontab) Oct 1 11:12:01 terrapin crond[1565]: (root) FAILED (loading cron table) Oct 1 11:12:01 terrapin crond[1565]: ((null)) No SELinux security context (/etc/cron.d/0hourly) Oct 1 11:12:01 terrapin crond[1565]: (root) FAILED (loading cron table) Oct 1 11:12:01 terrapin crond[1565]: ((null)) No SELinux security context (/etc/cron.d/sbackup) Oct 1 11:12:01 terrapin crond[1565]: (root) FAILED (loading cron table) Is your issue related to this BZ? https://bugzilla.redhat.com/show_bug.cgi?id=1862823 If so, it appears there's an issue with the selinux policy on your system. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: (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 crond[1565]: ((null)) No SELinux security context > (/etc/crontab) > Oct 1 11:12:01 terrapin crond[1565]: (root) FAILED (loading cron table) > Oct 1 11:12:01 terrapin crond[1565]: ((null)) No SELinux security context > (/etc/cron.d/0hourly) > Oct 1 11:12:01 terrapin crond[1565]: (root) FAILED (loading cron table) > Oct 1 11:12:01 terrapin crond[1565]: ((null)) No SELinux security context > (/etc/cron.d/sbackup) > Oct 1 11:12:01 terrapin crond[1565]: (root) FAILED (loading cron table) Is your issue related to this BZ? https://bugzilla.redhat.com/show_bug.cgi?id=1862823 If so, it appears there's an issue with the selinux policy on your system. -- Jonathan Billings ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
(root) FAILED (loading cron table)
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]: (root) FAILED (loading cron table)
Oct 1 11:12:01 terrapin crond[1565]: ((null)) No SELinux security
context (/etc/cron.d/0hourly)
Oct 1 11:12:01 terrapin crond[1565]: (root) FAILED (loading cron table)
Oct 1 11:12:01 terrapin crond[1565]: ((null)) No SELinux security
context (/etc/cron.d/sbackup)
Oct 1 11:12:01 terrapin crond[1565]: (root) FAILED (loading cron table)
ls -lZ /etc/cron.d/sbackup
-rw-r--r--. 1 root root unconfined_u:object_r:system_cron_spool_t:s0 76
Oct 1 11:11 /etc/cron.d/sbackup
ls -lZ /etc/cron.d/0hourly
-rw-r--r--. 1 root root system_u:object_r:system_cron_spool_t:s0 128 Jul
24 2019 /etc/cron.d/0hourly
ls -lZ /etc/crontab
-rw-r--r--. 1 root root system_u:object_r:system_cron_spool_t:s0 451 Jul
24 2019 /etc/crontab
ls -lZ /usr/sbin/sbackupd
-rwxr-xr-x. 1 root root system_u:object_r:usr_t:s0 21024 Apr 29 08:53
/usr/sbin/sbackupd*
I ran:
sudo sesearch -A -s unconfined_t -t user_cron_spool_t -c file
allow application_domain_type user_cron_spool_t:file { append getattr
ioctl lock read write };
allow crontab_domain user_cron_spool_t:file { append create getattr
ioctl link lock open read rename setattr unlink write };
allow domain file_type:file map; [ domain_can_mmap_files ]:True
allow files_unconfined_type file_type:file execmod; [
selinuxuser_execmod ]:True
allow files_unconfined_type file_type:file { append audit_access create
execute execute_no_trans getattr ioctl link lock map mounton open
quotaon read relabelfrom relabelto rename setattr swapon unlink write };
allow unconfined_t user_cron_spool_t:file entrypoint; [
cron_userdomain_transition ]:True
allow unconfined_t user_cron_spool_t:file { getattr ioctl read write };
This made no difference, my backups still don't run. The last backup
ran Aug 13.
What do I need to change to get my backups to start running
automatically again?
Paolo
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: cron is failing to run for selinux context, but everything looks fine
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 one.
I think it is already in place as the command
sesearch -A -s unconfined_t -t user_cron_spool_t -c file
found
allow application_domain_type user_cron_spool_t:file { append getattr ioctl
lock read write };
allow crontab_domain user_cron_spool_t:file { append create getattr ioctl link
lock open read rename setattr unlink write };
allow domain file_type:file map; [ domain_can_mmap_files ]:True
allow files_unconfined_type file_type:file execmod; [ selinuxuser_execmod ]:True
allow files_unconfined_type file_type:file { append audit_access create execute
execute_no_trans getattr ioctl link lock map mounton open quotaon read
relabelfrom relabelto rename setattr swapon unlink write };
allow unconfined_t user_cron_spool_t:file entrypoint; [
cron_userdomain_transition ]:True
allow unconfined_t user_cron_spool_t:file { getattr ioctl read write };
and the second from the bottom is that workaround.
> I think you should then wait on your BZ as well as you may want to
> join/ask on the selinux mailing list.
I agree, I'll wait a while to see if anything develops, and then ask
there. Hey, it is F31, so going end of life in a few months,
seems to work fine except for this corner case, so probably not a
priority.
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: cron is failing to run for selinux context, but everything looks fine
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 and /mnt. So I stopped it. It > looks like I can restrict fixfiles to specific directories, so I will > look into it. I have already used restorecon -r on /usr and /etc, which > should have picked up any problems. I also reinstalled cronie, to see > if a reinstall would correct any missing selinux context. No joy with > any of them. > > I think my next step will be to downgrade some of the updates from > July 25 to see if they are causing the problem. None of them look > likely. 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 one. I think you should then wait on your BZ as well as you may want to join/ask on the selinux mailing list. -- The key to getting good answers is to ask good questions. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: cron is failing to run for selinux context, but everything looks fine
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 restrict fixfiles to specific directories, so I will look into it. I have already used restorecon -r on /usr and /etc, which should have picked up any problems. I also reinstalled cronie, to see if a reinstall would correct any missing selinux context. No joy with any of them. I think my next step will be to downgrade some of the updates from July 25 to see if they are causing the problem. None of them look likely. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: cron is failing to run for selinux context, but everything looks fine
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 reboot? -- The key to getting good answers is to ask good questions. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: cron is failing to run for selinux context, but everything looks fine
On Thu, 30 Jul 2020 02:47:22 +0800 Ed Greshko wrote: > > In the above, is PID 5954 the crond process? If you run ps with the > -Z option do you get something like > > [egreshko@f31k ~]$ ps p 821 -Z > LABEL PID TTY STAT TIME COMMAND > system_u:system_r:crond_t:s0-s0:c0.c1023 821 ? Ss 0:00 > /usr/sbin/crond -n LABEL PID TTY STAT TIME COMMAND system_u:system_r:crond_t:s0-s0:c0.c1023 3167 ? Ss 0:00 /usr/sbin/crond -n > Do you happen to have another F31 system which doesn't 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 systems are running fine. > Jul 30 02:01:01 f31k.greshko.com CROND[2417]: (root) CMD (run-parts > /etc/cron.hourly) Jul 30 02:01:01 f31k.greshko.com run-parts[2420]: > (/etc/cron.hourly) starting 0anacron Jul 30 02:01:01 f31k.greshko.com > run-parts[2428]: (/etc/cron.hourly) finished 0anacron If I boot with enforcing=0 as a kernel option, I see this happen. > > Do you think having dwatch installed may be significant? And, did > you mention that in the bugzilla? It sounds to me like an important > detail. No, I don't think dwatch is significant, it is just the job I noticed. It was running fine on July 25, I updated, and on reboot on July 26, I see this behavior. I think this is the problem: crond[5954]: (*system*) NULL security context for user, but SELinux in permissive mode, continuing () crond only starts and runs properly when selinux is disabled. It hasn't been updated since last year, selinux was last updated in June, and the container-selinux package doesn't seem to have anything to do with this even though it was updated on July 25. With enforcing 0, restart crond, no dwatch Jul 29 12:25:03 localhost.localdomain crond[12307]: (CRON) INFO (@reboot jobs will be run at computer's startup.) Jul 29 12:25:03 localhost.localdomain crond[12307]: (CRON) INFO (running with inotify support) Jul 29 12:25:03 localhost.localdomain crond[12307]: ((null)) No security context but SELinux in permissive mode, continuing (/etc/cron.d/0hourly) Jul 29 12:25:03 localhost.localdomain crond[12307]: ((null)) No security context but SELinux in permissive mode, continuing (/etc/cron.d/atop) Jul 29 12:25:03 localhost.localdomain crond[12307]: ((null)) No security context but SELinux in permissive mode, continuing (/etc/cron.d/moodle) Jul 29 12:25:03 localhost.localdomain crond[12307]: ((null)) No security context but SELinux in permissive mode, continuing (/etc/cron.d/mailman) Jul 29 12:25:03 localhost.localdomain crond[12307]: ((null)) No security context but SELinux in permissive mode, continuing (/etc/cron.d/rear) Jul 29 12:25:03 localhost.localdomain crond[12307]: ((null)) No security context but SELinux in permissive mode, continuing (/etc/crontab) Jul 29 12:25:03 localhost.localdomain crond[12307]: (CRON) INFO (RANDOM_DELAY will be scaled with factor 30% if used.) Jul 29 12:25:03 localhost.localdomain crond[12307]: (CRON) STARTUP (1.5.4) Jul 29 12:25:03 localhost.localdomain systemd[1]: Started Command Scheduler. Jul 29 12:25:03 localhost.localdomain systemd[1]: Stopped Command Scheduler. Jul 29 12:25:03 localhost.localdomain systemd[1]: crond.service: Succeeded. Jul 29 12:25:03 localhost.localdomain crond[11695]: (CRON) INFO (Shutting down) Jul 29 12:25:03 localhost.localdomain systemd[1]: Stopping Command Scheduler... With enforcing 1, restart crond, no dwatch Jul 29 12:25:47 localhost.localdomain crond[12324]: (CRON) INFO (@reboot jobs will be run at computer's startup.) Jul 29 12:25:47 localhost.localdomain crond[12324]: (CRON) INFO (running with inotify support) Jul 29 12:25:47 localhost.localdomain crond[12324]: (root) FAILED (loading cron table) Jul 29 12:25:47 localhost.localdomain crond[12324]: ((null)) No SELinux security context (/etc/cron.d/0hourly) Jul 29 12:25:47 localhost.localdomain crond[12324]: (root) FAILED (loading cron table) Jul 29 12:25:47 localhost.localdomain crond[12324]: ((null)) No SELinux security context (/etc/cron.d/atop) Jul 29 12:25:47 localhost.localdomain crond[12324]: (root) FAILED (loading cron table) Jul 29 12:25:47 localhost.localdomain crond[12324]: ((null)) No SELinux security context (/etc/cron.d/moodle) Jul 29 12:25:46 localhost.localdomain crond[12324]: (root) FAILED (loading cron table) Jul 29 12:25:46 localhost.localdomain crond[12324]: ((null)) No SELinux security context (/etc/cron.d/mailman) Jul 29 12:25:46 localhost.localdomain crond[12324]: (root) FAILED (loading cron table) Jul 29 12:25:46 localhost.localdomain crond[12324]: ((null)) No SELinux security context (/etc/cron.d/rear) Jul 29 12:25:46 localhost.localdomain crond[12324]: (root) FAILED (loading cron table) J
Re: cron is failing to run for selinux context, but everything looks fine
On 2020-07-29 23:25, stan via users wrote: > On Wed, 29 Jul 2020 20:54:38 +0800 > Ed Greshko wrote: > >> So, dwatch is not part of Fedora. > Not now. Right. It was retired around F24 and you've rebuilt it locally to make a F31 package. >> 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 20:01:01 meimei.greshko.com >> run-parts[29645]: (/etc/cron.hourly) starting 0anacron Jul 29 >> 20:01:01 meimei.greshko.com run-parts[29651]: (/etc/cron.hourly) >> finished 0anacron > Returns nothing. > >>>> Then, just as a troubleshoot, have you tried running the system >>>> with setenforce 0? >>> I haven't, and that is a good suggestion. I'll reboot with >>> setenforce=0 on the kernel boot line. > I updated the bugzilla with the new information, but putting > enforcing=0 on the kernel boot line results in a working system again. > The messages change to allowing crond to run even though it has a NULL > security context because it is in security mode. I tried older kernels > from when it worked before, they also fail now, so not a kernel > problem. Somehow, the user that runs crond lost its selinux security > context. > > e.g. > > crond[5954]: (*system*) NULL security context for user, but SELinux in > permissive mode, continuing () > > and > > crond[1169]: ((null)) No security context but SELinux in permissive mode, > continuing (/etc/cron.d/dwatch) In the above, is PID 5954 the crond process? If you run ps with the -Z option do you get something like [egreshko@f31k ~]$ ps p 821 -Z LABEL PID TTY STAT TIME COMMAND system_u:system_r:crond_t:s0-s0:c0.c1023 821 ? Ss 0:00 /usr/sbin/crond -n Do you happen to have another F31 system which doesn't have dwatch installed? All of my F31 systems are running cron jobs just fine and they are all fully updated. Jul 30 02:01:01 f31k.greshko.com CROND[2417]: (root) CMD (run-parts /etc/cron.hourly) Jul 30 02:01:01 f31k.greshko.com run-parts[2420]: (/etc/cron.hourly) starting 0anacron Jul 30 02:01:01 f31k.greshko.com run-parts[2428]: (/etc/cron.hourly) finished 0anacron Do you think having dwatch installed may be significant? And, did you mention that in the bugzilla? It sounds to me like an important detail. -- The key to getting good answers is to ask good questions. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: cron is failing to run for selinux context, but everything looks fine
On Wed, 29 Jul 2020 20:54:38 +0800 Ed Greshko wrote: > So, dwatch is not part of Fedora. Not now. > On an F31 system... > > [egreshko@f31k ~]$ dnf info dwatch > Last metadata expiration check: 0:00:33 ago on Wed 29 Jul 2020 > 08:49:46 PM CST. Error: No matching Packages to list > > On an F32 system... > > [egreshko@meimei ~]$ dnf info dwatch > Last metadata expiration check: 4:12:49 ago on Wed 29 Jul 2020 > 04:35:59 PM CST. Error: No matching Packages to list > > So, where did you acquire it? https://koji.fedoraproject.org/koji/packageinfo?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 20:01:01 meimei.greshko.com > run-parts[29645]: (/etc/cron.hourly) starting 0anacron Jul 29 > 20:01:01 meimei.greshko.com run-parts[29651]: (/etc/cron.hourly) > finished 0anacron Returns nothing. > > >> Then, just as a troubleshoot, have you tried running the system > >> with setenforce 0? > > I haven't, and that is a good suggestion. I'll reboot with > > setenforce=0 on the kernel boot line. I updated the bugzilla with the new information, but putting enforcing=0 on the kernel boot line results in a working system again. The messages change to allowing crond to run even though it has a NULL security context because it is in security mode. I tried older kernels from when it worked before, they also fail now, so not a kernel problem. Somehow, the user that runs crond lost its selinux security context. e.g. crond[5954]: (*system*) NULL security context for user, but SELinux in permissive mode, continuing () and crond[1169]: ((null)) No security context but SELinux in permissive mode, continuing (/etc/cron.d/dwatch) ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: cron is failing to run for selinux context, but everything looks fine
On 2020-07-29 20:29, stan via users wrote: > On Wed, 29 Jul 2020 05:38:29 +0800 > Ed Greshko wrote: > >> On 2020-07-29 03:23, stan via users wrote: >>> 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 >> Could you clarify things a bit? > I'll try. > >> I still don't know what "daemon watch" is. What package/rpm supplies >> this? > Name: dwatch > Version : 0.1.1 > Release : 18.fc31 > Architecture: x86_64 > Install Date: Mon 10 Jun 2019 08:19:26 PM MST > Group : Applications/System > Size: 43883 > License : GPLv2+ > Signature : (none) > Source RPM : dwatch-0.1.1-18.fc31.src.rpm > Build Date : Mon 10 Jun 2019 08:18:22 PM MST > Build 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 example of what the file might look like. > > Dwatch is meant to be run from cron at regular intervals. So, dwatch is not part of Fedora. On an F31 system... [egreshko@f31k ~]$ dnf info dwatch Last metadata expiration check: 0:00:33 ago on Wed 29 Jul 2020 08:49:46 PM CST. Error: No matching Packages to list On an F32 system... [egreshko@meimei ~]$ dnf info dwatch Last metadata expiration check: 4:12:49 ago on Wed 29 Jul 2020 04:35:59 PM CST. Error: No matching Packages to list So, where did you acquire it? >> 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, which is it? > As far as I can tell, no cron jobs run. I noticed dwatch not running > because the entropy gathering daemons weren't running. The others run, > but their output isn't as noticeable to me. 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 20:01:01 meimei.greshko.com run-parts[29645]: (/etc/cron.hourly) starting 0anacron Jul 29 20:01:01 meimei.greshko.com run-parts[29651]: (/etc/cron.hourly) finished 0anacron >> Then, just as a troubleshoot, have you tried running the system with >> setenforce 0? > I haven't, and that is a good suggestion. I'll reboot with > setenforce=0 on the kernel boot line. > -- The key to getting good answers is to ask good questions. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: cron is failing to run for selinux context, but everything looks fine
On Wed, 29 Jul 2020 05:38:29 +0800 Ed Greshko wrote: > On 2020-07-29 03:23, stan via users wrote: > > 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 > > Could you clarify things a bit? I'll try. > I still don't know what "daemon watch" is. What package/rpm supplies > this? Name: dwatch Version : 0.1.1 Release : 18.fc31 Architecture: x86_64 Install Date: Mon 10 Jun 2019 08:19:26 PM MST Group : Applications/System Size: 43883 License : GPLv2+ Signature : (none) Source RPM : dwatch-0.1.1-18.fc31.src.rpm Build Date : Mon 10 Jun 2019 08:18:22 PM MST Build 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 example of what the file might look like. Dwatch is meant to be run from cron at regular intervals. > 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, which is it? As far as I can tell, no cron jobs run. I noticed dwatch not running because the entropy gathering daemons weren't running. The others run, but their output isn't as noticeable to me. > Then, just as a troubleshoot, have you tried running the system with > setenforce 0? I haven't, and that is a good suggestion. I'll reboot with setenforce=0 on the kernel boot line. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: cron is failing to run for selinux context, but everything looks fine
On 2020-07-29 03:23, stan via users wrote: > 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 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, which is it? Then, just as a troubleshoot, have you tried running the system with setenforce 0? -- The key to getting good answers is to ask good questions. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: cron is failing to run for selinux context, but everything looks fine
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 -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: cron is failing to run for selinux context, but everything looks fine
On Tue, 28 Jul 2020 11:53:15 -0700 Samuel Sieb wrote: > 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). 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 the cron jobs run. I only looked in /etc because the message said that /etc/crontab had the incorrect selinux context. > No SELinux security context (/etc/crontab) Everything has been running fine until recently, so there was an update that caused the issue. The main selinux policy updated on 6/12/2020, but container_selinux has been updated several times. That should have no effect here, since I don't run any containers, but ... I'll open a bugzilla. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: cron is failing to run for selinux context, but everything looks fine
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). ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: cron is failing to run for selinux context, but everything looks fine
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 journalctl, Are any other cron jobs running? Jul 28 10:07:08 localhost.localdomain crond[1192]: (root) FAILED (loading cron table) Jul 28 10:07:08 localhost.localdomain crond[1192]: ((null)) No SELinux security context (/etc/crontab) but when I check the security context, it seems fine to me. -rw-r--r--. 1 0 0 system_u:object_r:system_cron_spool_t:s0 451 Jul 24 2019 /etc/crontab I don't see how this is related to something in /etc/cron.d ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
cron is failing to run for selinux context, but everything looks fine
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.localdomain crond[1192]: (root) FAILED (loading cron table) Jul 28 10:07:08 localhost.localdomain crond[1192]: ((null)) No SELinux security context (/etc/crontab) but when I check the security context, it seems fine to me. -rw-r--r--. 1 0 0 system_u:object_r:system_cron_spool_t:s0 451 Jul 24 2019 /etc/crontab Before I open a bugzilla, I wanted to check if anyone has an explanation for this, and a fix. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: Starting and stopping RAID doesn't work from Cron
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 second before you mount it. In reality it will probably > happen much faster than 1sec. > > > I think the specific udev rule doing it is in > /lib/udev/rules.d/60-persistent-storage.rules and this happens after > udev processes the event when the device shows up. > > the link will be in /dev/disk/by-uuid/ so if once the mdadm exists do > a ls -l against that dir and then sleep a second and do it again > something new will show up. The journal is showing errors from udisksd immediately after the dock starts up from power-down, which may be because the mdadm check is running before the /sys/devices/... files are populated. I've changed the test to search for [UU] in /proc/mdstat to see if that works better. poc ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: Starting and stopping RAID doesn't work from Cron
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 faster than 1sec. I think the specific udev rule doing it is in /lib/udev/rules.d/60-persistent-storage.rules and this happens after udev processes the event when the device shows up. the link will be in /dev/disk/by-uuid/ so if once the mdadm exists do a ls -l against that dir and then sleep a second and do it again something new will show up. On Tue, Jun 23, 2020 at 11:45 AM Patrick O'Callaghan wrote: > > 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 as long as it is running, even if it is degraded. > > On second thoughts, that will only work if it's mounted, which happens > after I check that it's up. > > Thanks anyway. > > poc > ___ > users mailing list -- users@lists.fedoraproject.org > To unsubscribe send an email to users-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: Starting and stopping RAID doesn't work from Cron
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 as long as it is running, even if it is degraded. On second thoughts, that will only work if it's mounted, which happens after I check that it's up. Thanks anyway. poc ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: Starting and stopping RAID doesn't work from Cron
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 as long as it is running, even if it is degraded. > > > > If you want to be sure that it is running non-degraded then maybe look > > for "[UU]" in /proc/mdstat, assuming you just have a single RAID 1. Interesting ideas, thanks. poc ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: Starting and stopping RAID doesn't work from Cron
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 are using some other link then udev needs time
> > to
> > get the original mdXXX creation event and then create other links
> > pointing to mdXXX.
> >
> >
> >
>
> As I said earlier, it's being mounted via /etc/fstab thus:
>
> UUID=6cb66da2-147a-4f3c-a513-
> 36f6164ab581 /raid ext4rw,noauto,user 1
> 1
>
> where the script does:
>
> up) mounted && exit 0
> echo "- - -" > $SCAN
> echo -n "raid attempt: " >> $LOG
> for i in 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15;
> do# Wait up to 30 seconds
> sleep 2
> echo -n $i " " >> $LOG
> raidon && break
> done
> raidon || (echo -n " failed:"; date; exit
> 2)# RAID timed out
> (echo; echo -n "up: "; date) >> $LOG
> mount /raid > /dev/null 2>&1
> mounted || (echo "mount failed"; exit
> 3)# Mount failed
>
> and 'raidon' is defined as:
>
> function raidon() { # RAID drive is running
> if mdadm --query $RAID > /dev/null 2>&1 ; then
> return 0
> fi
> return 1
> }
>
> 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 as long as it is running, even if it is degraded.
If you want to be sure that it is running non-degraded then maybe look
for "[UU]" in /proc/mdstat, assuming you just have a single RAID 1.
> If
> that's not the case, then it would explain the issue.
>
> As can be seen, it's also doing a lot of logging. I can change it to
> run everything as a single script, but I don't really see what
> difference it will make. I'll report back on the results.
>
> poc
> ___
> users mailing list -- users@lists.fedoraproject.org
> To unsubscribe send an email to users-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines:
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
--
Doug H.
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: Starting and stopping RAID doesn't work from Cron
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 creation event and then create other links
> pointing to mdXXX.
>
>
>
As I said earlier, it's being mounted via /etc/fstab thus:
UUID=6cb66da2-147a-4f3c-a513-36f6164ab581 /raid ext4
rw,noauto,user 1 1
where the script does:
up) mounted && exit 0
echo "- - -" > $SCAN
echo -n "raid attempt: " >> $LOG
for i in 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15; do
# Wait up to 30 seconds
sleep 2
echo -n $i " " >> $LOG
raidon && break
done
raidon || (echo -n " failed:"; date; exit 2)
# RAID timed out
(echo; echo -n "up: "; date) >> $LOG
mount /raid > /dev/null 2>&1
mounted || (echo "mount failed"; exit 3)
# Mount failed
and 'raidon' is defined as:
function raidon() { # RAID drive is running
if mdadm --query $RAID > /dev/null 2>&1 ; then
return 0
fi
return 1
}
I'm assuming that once mdadm returns 0 the array is up and running. If
that's not the case, then it would explain the issue.
As can be seen, it's also doing a lot of logging. I can change it to
run everything as a single script, but I don't really see what
difference it will make. I'll report back on the results.
poc
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: Starting and stopping RAID doesn't work from Cron
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 creation event and then create other links pointing to mdXXX. And as someone else said, I would put it all in a single script and call that single script and add dates and echo's of various sorts and send both stderr and stdout to a log file. I usually just appended to the log file and then once in a while clear the file manually, but you can also just overwrite. On Tue, Jun 23, 2020 at 5:05 AM Patrick O'Callaghan wrote: > > 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 entry, > > better to have a simple /usr/local/bin/do_backup with the three commands > > inside. > > > > There you can log with "date" commands the execution the starting of each > > of the part > > > > and probably discover that the up part is working fine > > > > (md127: active with 2 out of 2 mirrors) > > > > then the backup script is failing (or not starting) and the down part is > > having problems, > > I'll consider that, but the script itself is already logging its > actions. > > > apparently shutting down disks while md is still active. > > Cron jobs have often problems with missing env variables (e.g. simplified > > PATH) > > , > > those can also be fixed if you go the do_backup approach. > > The script is called with a full path, so I don't think that's it, but > I guess I'll try it anyway. > > Thanks for the feedback. > > poc > ___ > users mailing list -- users@lists.fedoraproject.org > To unsubscribe send an email to users-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: Starting and stopping RAID doesn't work from Cron
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 entry, > better to have a simple /usr/local/bin/do_backup with the three commands > inside. > > There you can log with "date" commands the execution the starting of each of > the part > > and probably discover that the up part is working fine > > (md127: active with 2 out of 2 mirrors) > > then the backup script is failing (or not starting) and the down part is > having problems, I'll consider that, but the script itself is already logging its actions. > apparently shutting down disks while md is still active. > Cron jobs have often problems with missing env variables (e.g. simplified > PATH) > , > those can also be fixed if you go the do_backup approach. The script is called with a full path, so I don't think that's it, but I guess I'll try it anyway. Thanks for the feedback. poc ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: Starting and stopping RAID doesn't work from Cron
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. There you can log with "date" commands the execution the starting of each of the part and probably discover that the up part is working fine (md127: active with 2 out of 2 mirrors) then the backup script is failing (or not starting) and the down part is having problems, apparently shutting down disks while md is still active. Cron jobs have often problems with missing env variables (e.g. simplified PATH) , those can also be fixed if you go the do_backup approach. Regards. -- Roberto Ragusamail at robertoragusa.it ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: Starting and stopping RAID doesn't work from Cron
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 the md stopped or
> just put a simple few second sleep delay between the md stop and the
> disk stop.
I'll look at that (though I would think that when 'mdadm' returns it
means that md has in fact stopped), however the errors appear when
starting ('dock up'), not when stopping.
poc
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: Starting and stopping RAID doesn't work from Cron
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. On Sun, Jun 21, 2020 at 11:54 AM Patrick O'Callaghan wrote: > > 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 3am > > 0 3 * * * root /usr/local/bin/dock up && /usr/bin/borgmatic ; > /usr/local/bin/dock down > > The on/off script (see attached) works reliably when run from the > command line, but fails when run via cron. The journal shows the > following: > > Jun 21 03:00:01 Bree CROND[25480]: (root) CMD (/usr/local/bin/dock up && > /usr/bin/borgmatic ; /usr/local/bin/dock down) > Jun 21 03:00:01 Bree kernel: scsi 6:0:0:0: Direct-Access ASMT > ASM1156-PM 0PQ: 0 ANSI: 6 > Jun 21 03:00:01 Bree kernel: sd 6:0:0:0: Attached scsi generic sg4 type 0 > Jun 21 03:00:01 Bree kernel: sd 6:0:0:0: [sdd] 1953525168 512-byte logical > blocks: (1.00 TB/932 GiB) > Jun 21 03:00:01 Bree kernel: sd 6:0:0:0: [sdd] 4096-byte physical blocks > Jun 21 03:00:01 Bree kernel: scsi 6:0:0:1: Direct-Access ASMT > ASM1156-PM 0PQ: 0 ANSI: 6 > Jun 21 03:00:01 Bree kernel: sd 6:0:0:0: [sdd] Write Protect is off > Jun 21 03:00:01 Bree kernel: sd 6:0:0:0: [sdd] Mode Sense: 43 00 00 00 > Jun 21 03:00:01 Bree kernel: sd 6:0:0:0: [sdd] Write cache: enabled, read > cache: enabled, doesn't support DPO or FUA > Jun 21 03:00:01 Bree kernel: sd 6:0:0:1: Attached scsi generic sg5 type 0 > Jun 21 03:00:01 Bree kernel: sd 6:0:0:0: [sdd] Optimal transfer size 33553920 > bytes not a multiple of physical block size (4096 bytes) > Jun 21 03:00:01 Bree kernel: sd 6:0:0:1: [sde] 1953525168 512-byte logical > blocks: (1.00 TB/932 GiB) > Jun 21 03:00:01 Bree kernel: sd 6:0:0:1: [sde] 4096-byte physical blocks > Jun 21 03:00:01 Bree kernel: sd 6:0:0:1: [sde] Write Protect is off > Jun 21 03:00:01 Bree kernel: sd 6:0:0:1: [sde] Mode Sense: 43 00 00 00 > Jun 21 03:00:01 Bree kernel: sd 6:0:0:1: [sde] Write cache: enabled, read > cache: enabled, doesn't support DPO or FUA > Jun 21 03:00:01 Bree kernel: sd 6:0:0:1: [sde] Optimal transfer size 33553920 > bytes not a multiple of physical block size (4096 bytes) > Jun 21 03:00:06 Bree kernel: sd 6:0:0:0: [sdd] Attached SCSI disk > Jun 21 03:00:07 Bree kernel: sd 6:0:0:1: [sde] Attached SCSI disk > Jun 21 03:00:07 Bree udisksd[961]: Error reading sysfs attr > `/sys/devices/virtual/block/md127/md/degraded': Failed to open file > “/sys/devices/virtual/block/md127/md/degraded”: No such file or directory > (g-file> > Jun 21 03:00:07 Bree kernel: md/raid1:md127: active with 2 out of 2 mirrors > Jun 21 03:00:07 Bree udisksd[961]: Error reading sysfs attr > `/sys/devices/virtual/block/md127/md/sync_action': Failed to open file > “/sys/devices/virtual/block/md127/md/sync_action”: No such file or directory > (> > Jun 21 03:00:07 Bree udisksd[961]: Error reading sysfs attr > `/sys/devices/virtual/block/md127/md/sync_completed': Failed to open file > “/sys/devices/virtual/block/md127/md/sync_completed”: No such file or direc> > Jun 21 03:00:07 Bree udisksd[961]: Error reading sysfs attr > `/sys/devices/virtual/block/md127/md/degraded': Failed to open file > “/sys/devices/virtual/block/md127/md/degraded”: No such file or directory > (g-file> > Jun 21 03:00:07 Bree udisksd[961]: Error reading sysfs attr > `/sys/devices/virtual/block/md127/md/sync_action': Failed to open file > “/sys/devices/virtual/block/md127/md/sync_action”: No such file or directory > (> > Jun 21 03:00:07 Bree udisksd[961]: Error reading sysfs attr > `/sys/devices/virtual/block/md127/md/sync_completed': Failed to open file > “/sys/devices/virtual/block/md127/md/sync_completed”: No such file or direc> > Jun 21 03:00:07 Bree kernel: md127: detected capacity change from 0 to > 169595136 > Jun 21 03:00:07 Bree kernel: md127: p1 > Jun 21 03:00:07 Bree systemd[1]: Condition check resulted in Software RAID > monitoring and management being skipped. > Jun 21 03:00:07 Bree systemd[1]: Condition check resulted in Software RAID > monitoring and management being skipped. > Jun 21 03:00:31 Bree kernel: sd 6:0:0:0: [sdd] Synchronizing SCSI cache > Jun 21 03:00:31 Bree kernel: md/raid1:md127: Disk failure on sdd, disabling > device. <-* >
Starting and stopping RAID doesn't work from Cron
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 3am 0 3 * * * root /usr/local/bin/dock up && /usr/bin/borgmatic ; /usr/local/bin/dock down The on/off script (see attached) works reliably when run from the command line, but fails when run via cron. The journal shows the following: Jun 21 03:00:01 Bree CROND[25480]: (root) CMD (/usr/local/bin/dock up && /usr/bin/borgmatic ; /usr/local/bin/dock down) Jun 21 03:00:01 Bree kernel: scsi 6:0:0:0: Direct-Access ASMT ASM1156-PM 0PQ: 0 ANSI: 6 Jun 21 03:00:01 Bree kernel: sd 6:0:0:0: Attached scsi generic sg4 type 0 Jun 21 03:00:01 Bree kernel: sd 6:0:0:0: [sdd] 1953525168 512-byte logical blocks: (1.00 TB/932 GiB) Jun 21 03:00:01 Bree kernel: sd 6:0:0:0: [sdd] 4096-byte physical blocks Jun 21 03:00:01 Bree kernel: scsi 6:0:0:1: Direct-Access ASMT ASM1156-PM 0PQ: 0 ANSI: 6 Jun 21 03:00:01 Bree kernel: sd 6:0:0:0: [sdd] Write Protect is off Jun 21 03:00:01 Bree kernel: sd 6:0:0:0: [sdd] Mode Sense: 43 00 00 00 Jun 21 03:00:01 Bree kernel: sd 6:0:0:0: [sdd] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA Jun 21 03:00:01 Bree kernel: sd 6:0:0:1: Attached scsi generic sg5 type 0 Jun 21 03:00:01 Bree kernel: sd 6:0:0:0: [sdd] Optimal transfer size 33553920 bytes not a multiple of physical block size (4096 bytes) Jun 21 03:00:01 Bree kernel: sd 6:0:0:1: [sde] 1953525168 512-byte logical blocks: (1.00 TB/932 GiB) Jun 21 03:00:01 Bree kernel: sd 6:0:0:1: [sde] 4096-byte physical blocks Jun 21 03:00:01 Bree kernel: sd 6:0:0:1: [sde] Write Protect is off Jun 21 03:00:01 Bree kernel: sd 6:0:0:1: [sde] Mode Sense: 43 00 00 00 Jun 21 03:00:01 Bree kernel: sd 6:0:0:1: [sde] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA Jun 21 03:00:01 Bree kernel: sd 6:0:0:1: [sde] Optimal transfer size 33553920 bytes not a multiple of physical block size (4096 bytes) Jun 21 03:00:06 Bree kernel: sd 6:0:0:0: [sdd] Attached SCSI disk Jun 21 03:00:07 Bree kernel: sd 6:0:0:1: [sde] Attached SCSI disk Jun 21 03:00:07 Bree udisksd[961]: Error reading sysfs attr `/sys/devices/virtual/block/md127/md/degraded': Failed to open file “/sys/devices/virtual/block/md127/md/degraded”: No such file or directory (g-file> Jun 21 03:00:07 Bree kernel: md/raid1:md127: active with 2 out of 2 mirrors Jun 21 03:00:07 Bree udisksd[961]: Error reading sysfs attr `/sys/devices/virtual/block/md127/md/sync_action': Failed to open file “/sys/devices/virtual/block/md127/md/sync_action”: No such file or directory (> Jun 21 03:00:07 Bree udisksd[961]: Error reading sysfs attr `/sys/devices/virtual/block/md127/md/sync_completed': Failed to open file “/sys/devices/virtual/block/md127/md/sync_completed”: No such file or direc> Jun 21 03:00:07 Bree udisksd[961]: Error reading sysfs attr `/sys/devices/virtual/block/md127/md/degraded': Failed to open file “/sys/devices/virtual/block/md127/md/degraded”: No such file or directory (g-file> Jun 21 03:00:07 Bree udisksd[961]: Error reading sysfs attr `/sys/devices/virtual/block/md127/md/sync_action': Failed to open file “/sys/devices/virtual/block/md127/md/sync_action”: No such file or directory (> Jun 21 03:00:07 Bree udisksd[961]: Error reading sysfs attr `/sys/devices/virtual/block/md127/md/sync_completed': Failed to open file “/sys/devices/virtual/block/md127/md/sync_completed”: No such file or direc> Jun 21 03:00:07 Bree kernel: md127: detected capacity change from 0 to 169595136 Jun 21 03:00:07 Bree kernel: md127: p1 Jun 21 03:00:07 Bree systemd[1]: Condition check resulted in Software RAID monitoring and management being skipped. Jun 21 03:00:07 Bree systemd[1]: Condition check resulted in Software RAID monitoring and management being skipped. Jun 21 03:00:31 Bree kernel: sd 6:0:0:0: [sdd] Synchronizing SCSI cache Jun 21 03:00:31 Bree kernel: md/raid1:md127: Disk failure on sdd, disabling device. <-* md/raid1:md127: Operation continuing on 1 devices. Jun 21 03:00:31 Bree kernel: sd 6:0:0:1: [sde] Synchronizing SCSI cache Jun 21 03:00:31 Bree udisksd[961]: Unable to resolve /sys/devices/virtual/block/md127/md/dev-sde/block symlink Jun 21 03:00:31 Bree udisksd[961]: Unable to resolve /sys/devices/virtual/block/md127/md/dev-sdd/block symlink Jun 21 03:00:31 Bree udisksd[961]: Unable to resolve /sys/devices/virtual/block/md127/md/dev-sde/block symlink Jun 21 03:00:31 Bree udisksd[961]: Unable to resolve /sys/devices/virtual/block/md127/md/dev-sdd/block symlink Jun 21 03:00:31 Bree kernel: md: super_written gets error=10 Jun 21 03:00:31 Bree kernel: md127: detected capacity change from 169595136 to 0 Jun 21 03
Re: formail - Re: Fedora 32 no MTA, CRON output and procmail
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 MTA. I don't think it is dependent on having a MTA. It runs without it. It even gives reports in a log. On the other hand, I think if you want reports as emails, the easiest thing is to run one, rather than reinvent the wheel. It's easy to add one, the default installation works for local mail. And does so without making your machine vulnerable as a spambot. It takes a few minutes to do, rather than several days to try and bypass. The only value I see in doing what Robert's trying, is to learn more about how email works. -- uname -rsvp Linux 3.10.0-1127.el7.x86_64 #1 SMP Tue Mar 31 23:36:51 UTC 2020 x86_64 Boilerplate: All unexpected mail to my mailbox is automatically deleted. I will only get to see the messages that are posted to the mailing list. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
thank you - cron mailer script
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 procmail. Here is the 'final' script: local]# cat mycron #!/bin/sh # the sed commands only work if USER == MAILTO in crontab exec 3>> /var/spool/mail/$USER exec 100>/var/tmp/$USERlock.lock || exit 1 flock -w 120 100 || exit 1 currentDate=$(date +'%a %b %d %T %Y') echo "From cron@localhost $currentDate" >&3 currentDate2=$(date +'%a, %e %b %Y %T %z (%Z)') echo "Date: $currentDate2" >&3 echo "Message-ID: $(uuidgen)@$HOSTNAME" >&3 # (cat) >&3 (sed -e "/^From: / s/$USER/$USER@$HOSTNAME/"|sed -e "/^To: / s/$USER/$USER@$HOSTNAME/") >&3 echo "" >&3 Again, thanks ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: formail - Re: Fedora 32 no MTA, CRON output and procmail
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 will be submitting this whole shebang as a bug. Why not just have your crontab call a script? #!/bin/sh echo Start Time `date` rsync ... echo End Time `date` I think if I run my rsync tasks within time, I would get this, but the problem is more the post processing. Here is my post processing script so far: local]# cat mycron #!/bin/sh exec 3>> /var/spool/mail/$USER currentDate=$(date +'%a %b %d %T %Y') echo "From cron@localhost $currentDate" >&3 currentDate2=$(date +'%a, %e %b %Y %T %z (%Z)') echo "Date: $currentDate2" >&3 (cat) >&3 echo "" >&3 I suspect I could add a couple of sed commands acting on file &3 to fix the FROM and TO headers, adding the hostname... Probably could also work out something for a MESSAGE-ID header. Oh, I am having selinux problems with this script for cron tasks run as root. I have submitted a question about it to the selinux list. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: formail - Re: Fedora 32 no MTA, CRON output and procmail
On 5/10/20 11:51 PM, Ed Greshko wrote: On 2020-05-11 11:33, Robert Moskowitz wrote: 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 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)')" -s procmail where stdin is the output from cron puts the "proper" email into /var/spool/mail/user but how to get this into the crondargs line and get the quotes right? 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. No it does not. This is what the CRONARGS -m option in /etc/sysconfig/cron is for. It replaces the default: mailer="sendmail -t" option with your own shell script. What I did in my rather late response was to just install and start postfix. I made no configuration. And I think that is what you were looking to do. Just get mail in the local inbox for cron jobs. Am I missing something? 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 MTA. Of course this is all a matter of opinion. :) ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: formail - Re: Fedora 32 no MTA, CRON output and procmail
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 > this whole shebang as a bug. Why not just have your crontab call a script? #!/bin/sh echo Start Time `date` rsync ... echo End Time `date` -- The key to getting good answers is to ask good questions. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: formail - Re: Fedora 32 no MTA, CRON output and procmail
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 with Return-Path: Delivered-To: Received: by Message-Id: Date: The MTA modifies the From: and To: lines to add a FQDN. And, yes, not all of those are "required". I was of the understanding that a "From line" is a MBOX thing, different from the From: header of an email. I knew Message-Id isn't required to be supplied from the authoring program, though having a unique ID right from the start would make it easier to identify all messages from start to finish (identify on the originator's archive of their sent messages before it went out to a SMTP server, with its return and replies, etc). Many of the other possible headers are also part of the mail delivery system, so wouldn't actually come from the message authoring program. I'd (logically) expect the SMTP server to fill in return-path, etc. Here is a sample of the headers provided by cron: From: "(Cron Daemon)" To: rgm Subject: Cron rsync -tvz rsync.tools.ietf.org::tools.id/*-hip-*.xml /home/common/ietf/drafts/xml MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Auto-Submitted: auto-generated Precedence: bulk X-Cron-Env: X-Cron-Env: X-Cron-Env: X-Cron-Env: X-Cron-Env: X-Cron-Env: X-Cron-Env: X-Cron-Env: X-Cron-Env: X-Cron-Env: X-Cron-Env: X-Cron-Env: Status: RO Content-Length: 101 Lines: 3 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 this whole shebang as a bug. :) The FROM: header could be better as <$USER@$HOSTNAME>, but HOSTNAME is not one of the env variable know to cron. Yet another bug. ;) The TO: header is the same concern. Would be better, but it works as is. No DATE: really is a problem. MESSAGE-ID: would be a nice addition. All improvements that SHOULD be provided by cron, not a post-processor. I am sure I could fix my script to do all of these, other than the datetime cron started the task. I might still ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: formail - Re: Fedora 32 no MTA, CRON output and procmail
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. >> >> From egreshko . is missing along with >> Return-Path: >> Delivered-To: >> Received: by >> Message-Id: >> Date: >> The MTA modifies the From: and To: lines to add a FQDN. >> >> And, yes, not all of those are "required". > I was of the understanding that a "From line" is a MBOX thing, > different from the From: header of an email. Correct. By default, it seems postfix delivers to /var/spool/mail in MBOX format. Don't know, and don't care, if that is configurable. > I knew Message-Id isn't required to be supplied from the authoring > program, though having a unique ID right from the start would make it > easier to identify all messages from start to finish (identify on the > originator's archive of their sent messages before it went out to a > SMTP server, with its return and replies, etc). > > Many of the other possible headers are also part of the mail delivery > system, so wouldn't actually come from the message authoring program. > I'd (logically) expect the SMTP server to fill in return-path, etc. > Right. -- The key to getting good answers is to ask good questions. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: formail - Re: Fedora 32 no MTA, CRON output and procmail
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-Path: > Delivered-To: > Received: by > Message-Id: > Date: > The MTA modifies the From: and To: lines to add a FQDN. > > And, yes, not all of those are "required". I was of the understanding that a "From line" is a MBOX thing, different from the From: header of an email. I knew Message-Id isn't required to be supplied from the authoring program, though having a unique ID right from the start would make it easier to identify all messages from start to finish (identify on the originator's archive of their sent messages before it went out to a SMTP server, with its return and replies, etc). Many of the other possible headers are also part of the mail delivery system, so wouldn't actually come from the message authoring program. I'd (logically) expect the SMTP server to fill in return-path, etc. -- uname -rsvp Linux 3.10.0-1127.el7.x86_64 #1 SMP Tue Mar 31 23:36:51 UTC 2020 x86_64 Boilerplate: All unexpected mail to my mailbox is automatically deleted. I will only get to see the messages that are posted to the mailing list. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: formail - Re: Fedora 32 no MTA, CRON output and procmail
On 2020-05-11 17:20, Tim via users wrote: > 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 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 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-Path: Delivered-To: Received: by Message-Id: Date: The MTA modifies the From: and To: lines to add a FQDN. And, yes, not all of those are "required". -- The key to getting good answers is to ask good questions. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: formail - Re: Fedora 32 no MTA, CRON output and procmail
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 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. -- uname -rsvp Linux 3.10.0-1127.el7.x86_64 #1 SMP Tue Mar 31 23:36:51 UTC 2020 x86_64 Boilerplate: All unexpected mail to my mailbox is automatically deleted. I will only get to see the messages that are posted to the mailing list. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: formail - Re: Fedora 32 no MTA, CRON output and procmail
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 a script that saved what is being sent to it by cron. These are the resulting headers. From: "(Cron Daemon)" To: egreshko Subject: Cron /home/egreshko/bin/tippy MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Auto-Submitted: auto-generated Precedence: bulk X-Cron-Env: X-Cron-Env: X-Cron-Env: X-Cron-Env: X-Cron-Env: X-Cron-Env: X-Cron-Env: X-Cron-Env: X-Cron-Env: X-Cron-Env: X-Cron-Env: X-Cron-Env: It is then the MTA, in my case postfix, which adds the additional headers. -- The key to getting good answers is to ask good questions. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: formail - Re: Fedora 32 no MTA, CRON output and procmail
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. > > Robert doesn't want to put an MTA in. It looks like the cron -m argument lets > you specify the command used to dispatch email, normally sendmail. However, > by using procmail he doesn't need an MTA because he's having procmail do > delivery directly. In that circumstance you don't need an MTA and therefore, > you don't need a running MTA. > > Personally I'm having trouble finding the doco for the -m option, and also > don't know where he's putting this setting. The setting goes in /etc/sysconfig/crond. From the crond man page -m This option allows you to specify a shell command to use for sending Cron mail output instead of using sendmail(8) This com‐ mand must accept a fully formatted mail message (with headers) on standard input and send it as a mail message to the recipients specified in the mail headers. Specifying the string off (i.e., crond -m off) will disable the sending of mail. I don't understand what is gained by not installing postfix and letting it only listen, by default, on "localhost" and use the standard methods for getting mail from cron. 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. -- The key to getting good answers is to ask good questions. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: formail - Re: Fedora 32 no MTA, CRON output and procmail
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 specify the command used to dispatch email, normally sendmail. However, by using procmail he doesn't need an MTA because he's having procmail do delivery directly. In that circumstance you don't need an MTA and therefore, you don't need a running MTA. Personally I'm having trouble finding the doco for the -m option, and also don't know where he's putting this setting. Cheers, Cameron Simpson ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: formail - Re: Fedora 32 no MTA, CRON output and procmail
On 2020-05-11 11:33, Robert Moskowitz wrote: > 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 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)')" -s procmail > > where stdin is the output from cron puts the "proper" email into > /var/spool/mail/user > > but how to get this into the crondargs line and get the quotes right? > > 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. What I did in my rather late response was to just install and start postfix. I made no configuration. And I think that is what you were looking to do. Just get mail in the local inbox for cron jobs. Am I missing something? -- The key to getting good answers is to ask good questions. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
formail - Re: Fedora 32 no MTA, CRON output and procmail
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 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)')" -s procmail where stdin is the output from cron puts the "proper" email into /var/spool/mail/user but how to get this into the crondargs line and get the quotes right? ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Fedora 32 no MTA, CRON output and procmail
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" So I just tried this and I have one problem with it. No DATE header. So my new script is better, so far, than procmail. That is until someone tells me how to get procmail to add a DATE header. Or maybe better for CRON to put it in, and the DATE/TIME it started the task, not when PROCMAIL would process the output. thanks BTW, Here is my current mycron script: local]# cat mycron #!/bin/sh exec 3>> /var/spool/mail/$USER currentDate=$(date +'%a %b %d %T %Y') echo "From cron@localhost $currentDate" >&3 currentDate2=$(date +'%a, %e %b %Y %T %z (%Z)') echo "Date: $currentDate2" >&3 (cat) >&3 echo "" >&3 Thanks for all the help getting to this point. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: Logwatch cron job
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 Linux 3.10.0-1127.el7.x86_64 #1 SMP Tue Mar 31 23:36:51 UTC 2020 x86_64 Boilerplate: All unexpected mail to my mailbox is automatically deleted. I will only get to see the messages that are posted to the mailing list. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: Logwatch cron job
On Fri, 08 May 2020 10:26:05 -0400 Robert Moskowitz wrote: > On 5/8/20 10:18 AM, francis.montag...@inria.fr wrote: >> By using 'systemctl restart' you invoked the later that do not use >> /etc/logwatch/conf/logwatch.conf ... > Ooops. > So to get things back to 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 immediately except if you change temporarily the start time of the cron job. > or do something to kick it off on the next cron hourly...? No need thus. -- francis ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: Logwatch cron job
On 5/8/20 10:18 AM, francis.montag...@inria.fr wrote:
Hi.
On Fri, 08 May 2020 09:51:13 -0400 Robert Moskowitz wrote:
May 8 03:27:17 lx140e run-parts[66530]: (/etc/cron.daily) finished 0logwatch
So it looks like I need to modify /etc/logwatch/conf/logwatch.conf with
mailer = "/usr/local/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"
What happens after I made this change and then "systemctl restart 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 'systemctl restart' you invoked the later that do not use
/etc/logwatch/conf/logwatch.conf but instead:
# This first EnvironmentFile has the Logwatch default variables
EnvironmentFile=-/usr/share/logwatch/default.conf/systemd.conf
# This second EnvironmentFile is meant for system-specific
# customization of variables, including overriding the defaults
EnvironmentFile=-/etc/logwatch/conf/systemd.conf
Ooops.
So to get things back to how they were:
systemctl stop logwatch
And then wait until cron.daily
or do something to kick it off on the next cron hourly...
?
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: Logwatch cron job
Hi.
On Fri, 08 May 2020 09:51:13 -0400 Robert Moskowitz wrote:
>> May 8 03:27:17 lx140e run-parts[66530]: (/etc/cron.daily) finished 0logwatch
>> So it looks like I need to modify /etc/logwatch/conf/logwatch.conf with
>> mailer = "/usr/local/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"
> What happens after I made this change and then "systemctl restart 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 'systemctl restart' you invoked the later that do not use
/etc/logwatch/conf/logwatch.conf but instead:
# This first EnvironmentFile has the Logwatch default variables
EnvironmentFile=-/usr/share/logwatch/default.conf/systemd.conf
# This second EnvironmentFile is meant for system-specific
# customization of variables, including overriding the defaults
EnvironmentFile=-/etc/logwatch/conf/systemd.conf
--
francis
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: Logwatch cron job
On 5/8/20 8:23 AM, Robert Moskowitz wrote: 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 sequentially May 8 03:01:02 lx140e run-parts[66123]: (/etc/cron.hourly) finished 0anacron May 8 03:27:02 lx140e anacron[66134]: Job `cron.daily' started May 8 03:27:02 lx140e run-parts[66530]: (/etc/cron.daily) starting 0logwatch May 8 03:27:17 lx140e run-parts[66530]: (/etc/cron.daily) finished 0logwatch May 8 03:27:17 lx140e anacron[66134]: Job `cron.daily' terminated (produced output) May 8 03:27:17 lx140e anacron[66134]: Normal exit (1 job run) but no /var/spool/mail/root So a little digging and I find in /usr/share/logwatch/default.conf/logwatch.conf # By default we assume that all Unix systems have sendmail or a sendmail-like MTA. # The mailer code prints a header with To: From: and Subject:. # At this point you can change the mailer to anything that can handle this output # stream. # TODO test variables in the mailer string to see if the To/From/Subject can be set # From here with out breaking anything. This would allow mail/mailx/nail etc. -mgt mailer = "/usr/sbin/sendmail -t" So it looks like I need to modify /etc/logwatch/conf/logwatch.conf with mailer = "/usr/local/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 %d %T %Y')" echo "From cron@localhost $currentDate" >> /var/spool/mail/$USER (cat; echo) >> /var/spool/mail/$USER What happens after I made this change and then "systemctl restart logwatch" was for logwatch to send its output to /var/log/messages So what am I missing? ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Logwatch cron job
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 sequentially May 8 03:01:02 lx140e run-parts[66123]: (/etc/cron.hourly) finished 0anacron May 8 03:27:02 lx140e anacron[66134]: Job `cron.daily' started May 8 03:27:02 lx140e run-parts[66530]: (/etc/cron.daily) starting 0logwatch May 8 03:27:17 lx140e run-parts[66530]: (/etc/cron.daily) finished 0logwatch May 8 03:27:17 lx140e anacron[66134]: Job `cron.daily' terminated (produced output) May 8 03:27:17 lx140e anacron[66134]: Normal exit (1 job run) but no /var/spool/mail/root So a little digging and I find in /usr/share/logwatch/default.conf/logwatch.conf # By default we assume that all Unix systems have sendmail or a sendmail-like MTA. # The mailer code prints a header with To: From: and Subject:. # At this point you can change the mailer to anything that can handle this output # stream. # TODO test variables in the mailer string to see if the To/From/Subject can be set # From here with out breaking anything. This would allow mail/mailx/nail etc. -mgt mailer = "/usr/sbin/sendmail -t" So it looks like I need to modify /etc/logwatch/conf/logwatch.conf with mailer = "/usr/local/mycron" And see what happens next. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: Cron sometimes starts two jobs from the same crontab entry
On 09/04/2020 12:24, Ed Greshko wrote: 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 at Tue 7 Apr 23:01:01 BST 2020 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 at Tue 7 Apr 23:01:01 BST 2020 Backup aborted as locked by another backup Just wondering, if you look at the journal output for that date and time do you see it being started twice? For example, I have 2 jobs that start at 19:00 each day and for each time they are started I'd see... Apr 09 19:00:01 meimei.greshko.com CROND[76409]: (egreshko) CMD (/home/egreshko/bin/getpics-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 /opt /scratch /data/svn /data/www /data/vwt /data/www /data1/kvm /data/database /data/vwt /data/backup at Wed 8 Apr 23:01:01 BST 2020 Bbackup 27200 / /usr/beam /home /src /srcOld /dist /opt /scratch /data/svn /data/www /data/vwt /data/www /data1/kvm /data/database /data/vwt /data/backup at Wed 8 Apr 23:01:01 BST 2020 Backup aborted as locked by another backup Bbackup completed status: 0 at Thu 9 Apr 01:29:24 BST 2020 #/var/log/cron Apr 8 22:01:01 beam CROND[804585]: (root) CMD (/src/bbackup/bbackup-test1) Apr 8 22:01:01 beam CROND[804586]: (root) CMD (run-parts /etc/cron.hourly) Apr 8 22:01:01 beam CROND[804583]: (root) CMDOUT (Starting Bbackup-test1) Apr 8 22:01:01 beam run-parts[804586]: (/etc/cron.hourly) starting 0anacron Apr 8 22:01:01 beam run-parts[804586]: (/etc/cron.hourly) finished 0anacron Apr 8 23:01:01 beam CROND[805474]: (root) CMD (/src/bbackup/bbackup-test1) Apr 8 23:01:01 beam CROND[805475]: (root) CMD (run-parts /etc/cron.hourly) Apr 8 23:01:01 beam CROND[805476]: (root) CMD (/src/bbackup/bbackup-beam) Apr 8 23:01:01 beam CROND[805471]: (root) CMDOUT (Starting Bbackup-test1) Apr 8 23:01:01 beam run-parts[805475]: (/etc/cron.hourly) starting 0anacron Apr 8 23:01:01 beam CROND[805473]: (root) CMDOUT (Waking up 70:85:c2:0f:68:07...) Apr 8 23:01:01 beam run-parts[805475]: (/etc/cron.hourly) finished 0anacron Apr 8 23:01:21 beam CROND[805473]: (root) CMDOUT (Starting Backup) Apr 9 00:01:01 beam CROND[806518]: (root) CMD (run-parts /etc/cron.hourly) Apr 9 00:01:01 beam CROND[806519]: (root) CMD (/src/bbackup/bbackup-test1) Strange low PID for second bbackup-beam script run ... Ahggh found it! There was a VM running on our network of an older development Fedora platform based on an image of our old server and it still had its backup system running as the cron table entry was still there! Sorry for all the noise. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: Cron sometimes starts two jobs from the same crontab entry
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 at Tue 7 Apr 23:01:01 BST 2020 > 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 at Tue 7 Apr 23:01:01 BST 2020 > Backup aborted as locked by another backup Just wondering, if you look at the journal output for that date and time do you see it being started twice? For example, I have 2 jobs that start at 19:00 each day and for each time they are started I'd see... Apr 09 19:00:01 meimei.greshko.com CROND[76409]: (egreshko) CMD (/home/egreshko/bin/getpics-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? -- The key to getting good answers is to ask good questions. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: Cron sometimes starts two jobs from the same crontab entry
On 09/04/2020 07:00, francis.montag...@inria.fr wrote:
Hi
On Tue, 07 Apr 2020 07:07:36 +0100 Terry Barnaby wrote:
# Min Hour Day Month WeekDay
# Perform incremental backup to every work day
01 23 * * 1 root /src/bbackup/bbackup-beam
01 23 * * 2 root /src/bbackup/bbackup-beam
01 23 * * 3 root /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 occasionally.
I have seen that also a few time, but years ago.
I have had to add a file lock system in the bbackup-beam to cope with this.
I did the same, also for frequent cron jobs that may be stuck for a
too long time, for example if a network outage occurs.
Then (years later) an alternative to cron appeared: systemd.timer.
Pros:
- Gratuitous execution locking
"systemctl start X" is a noop if X runs.
- Ease log management
By default in the system log.
No more need to redirect stdout and stderr to /dev/null as seen
in so many crontabs
- Ease tracking processes
With "systemctl status" "systemctl stop" ...
Cons:
- It's systemd-ish :-)
I can show you how to convert your crontab to systemd.{service,timer}
if you want.
Many thanks. I do use systemd for some things, especially daemon
management, but this is an old (was reliable) system and it is also used
on some much older systems. The cron config is very simple,
understandable and its configuration files are not lost in systemd's
noise. I think I will keep with cron (while it is still available!) for
now. As stated it is functions with the lock, I was just feeding back
the issue in-case there is actually a problem in the system here.
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: Cron sometimes starts two jobs from the same crontab entry
On 08/04/2020 23:11, Cameron Simpson wrote: On 08Apr2020 14:54, Terry Barnaby wrote: 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 resyncs I suppose but I think something stranger is going on here or 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. Makes sure the job is actually starting at the cron time. Might tell you more about the system time situation. Cheers, Cameron Simpson ___ 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 at Tue 7 Apr 23:01:01 BST 2020 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 at Tue 7 Apr 23:01:01 BST 2020 Backup aborted as locked by another backup Bbackup completed status: 0 at Wed 8 Apr 00:58:57 BST 2020 Bbackup 805476 / /usr/beam /home /src /srcOld /dist /opt /scratch /data/svn /data/www /data/vwt /data/www /data1/kvm /data/database /data/vwt /data/backup at Wed 8 Apr 23:01:01 BST 2020 Bbackup 27200 / /usr/beam /home /src /srcOld /dist /opt /scratch /data/svn /data/www /data/vwt /data/www /data1/kvm /data/database /data/vwt /data/backup at Wed 8 Apr 23:01:01 BST 2020 Backup aborted as locked by another backup Bbackup completed status: 0 at Thu 9 Apr 01:29:24 BST 2020 I will change it to show down to the us. Terry ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: Cron sometimes starts two jobs from the same crontab entry
Hi
On Tue, 07 Apr 2020 07:07:36 +0100 Terry Barnaby wrote:
> # Min Hour Day Month WeekDay
> # Perform incremental backup to every work day
> 01 23 * * 1 root /src/bbackup/bbackup-beam
> 01 23 * * 2 root /src/bbackup/bbackup-beam
> 01 23 * * 3 root /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 occasionally.
I have seen that also a few time, but years ago.
> I have had to add a file lock system in the bbackup-beam to cope with this.
I did the same, also for frequent cron jobs that may be stuck for a
too long time, for example if a network outage occurs.
Then (years later) an alternative to cron appeared: systemd.timer.
Pros:
- Gratuitous execution locking
"systemctl start X" is a noop if X runs.
- Ease log management
By default in the system log.
No more need to redirect stdout and stderr to /dev/null as seen
in so many crontabs
- Ease tracking processes
With "systemctl status" "systemctl stop" ...
Cons:
- It's systemd-ish :-)
I can show you how to convert your crontab to systemd.{service,timer}
if you want.
--
francis
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: Cron sometimes starts two jobs from the same crontab entry
On 08Apr2020 14:54, Terry Barnaby wrote: 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 resyncs I suppose but I think something stranger is going on here or 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. Makes sure the job is actually starting at the cron time. Might tell you more about the system time situation. Cheers, Cameron Simpson ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: Cron sometimes starts two jobs from the same crontab entry
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 happen twice if 2am steps back to 1am. Our summer time just ended here. Might a similar shift have happened for you? Well, except that the format of the crontab is Minute Hour Day-of-Month . :-) Um, indeed, as you say. I thought about that after my post, too late. Cheers, Cameron Simpson ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: Cron sometimes starts two jobs from the same crontab entry
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 US. A few years ago, this allowed a three hour performance of Rocky Horror to fit into a two hour time slot. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: Cron sometimes starts two jobs from the same crontab entry
On 2020-04-08 21:37, Patrick O'Callaghan wrote: > On Wed, 2020-04-08 at 20:28 +0800, Ed Greshko 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. >>> >> 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. > 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. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: Cron sometimes starts two jobs from the same crontab entry
On 08/04/2020 14:37, Patrick O'Callaghan wrote: On Wed, 2020-04-08 at 20:28 +0800, Ed Greshko 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. 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. 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. 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 resyncs I suppose but I think something stranger is going on here or 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 ... Terry ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: Cron sometimes starts two jobs from the same crontab entry
On Wed, 2020-04-08 at 20:28 +0800, Ed Greshko 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. > > > > 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. 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. poc ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: Cron sometimes starts two jobs from the same crontab entry
On 2020-04-08 20:21, Patrick O'Callaghan wrote:
> 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/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 similar shift have happened for
>>>>> you?
>>>> Well, except that the format of the crontab is
>>>>
>>>> Minute Hour Day-of-Month .
>>> How does that avoid the problem? The same time can still happen twice.
>>>
>>
>>
>> How can 23:01 happen twice at the switch to/from DST?
> It can happen when switching from summer time (i.e. "fall back"),
> though not on switching to summer time ("spring forward"), which of
> course is the OP's case.
>
> 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.
>
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 saving time 2020 in United Kingdom began at 1:00 AM on
Sunday, March 29
and ends at 2:00 AM on
Sunday, October 25
All times are in United Kingdom Time.
Not near 23:01 which is the OP's cron start time.
--
The key to getting good answers is to ask good questions.
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: Cron sometimes starts two jobs from the same crontab entry
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 avoided. Good point. poc ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: Cron sometimes starts two jobs from the same crontab entry
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/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 similar shift have happened
> > > > for you?
> > > Well, except that the format of the crontab is
> > >
> > > Minute Hour Day-of-Month .
> > How does that avoid the problem? The same time can still happen twice.
> >
>
>
>
> How can 23:01 happen twice at the switch to/from DST?
It can happen when switching from summer time (i.e. "fall back"),
though not on switching to summer time ("spring forward"), which of
course is the OP's case.
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.
poc
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: Cron sometimes starts two jobs from the same crontab entry
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 Local time changes of less than three hours, such as those caused by the Daylight Saving Time changes, are handled in a special way. This only applies to jobs that run at a specific time and jobs that run with a granularity greater than one hour. Jobs that run more frequently are scheduled normally. 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 avoided. Time changes of more than 3 hours are considered to be corrections to the clock or the timezone, and the new time is used immediately. It is possible to use different time zones for crontables. See crontab(5) for more information. -- The key to getting good answers is to ask good questions. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: Cron sometimes starts two jobs from the same crontab entry
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, 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 similar shift have happened for you? >>> Well, except that the format of the crontab is >>> >>> Minute Hour Day-of-Month . >> How does that avoid the problem? The same time can still happen twice. >> > > > > How can 23:01 happen twice at the switch to/from DST? > > -- > The key to getting good answers is to ask good questions. > ___ > users mailing list -- users@lists.fedoraproject.org > To unsubscribe send an email to users-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: Cron sometimes starts two jobs from the same crontab entry
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 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 similar shift have happened for >>> you? >> Well, except that the format of the crontab is >> >> Minute Hour Day-of-Month . > How does that avoid the problem? The same time can still happen twice. > How can 23:01 happen twice at the switch to/from DST? -- The key to getting good answers is to ask good questions. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: Cron sometimes starts two jobs from the same crontab entry
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 it happened at 12am). So 1:23am can happen twice if 2am steps > > back to 1am. > > > > Our summer time just ended here. Might a similar shift have happened for > > you? > > Well, except that the format of the crontab is > > Minute Hour Day-of-Month . How does that avoid the problem? The same time can still happen twice. poc ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: Cron sometimes starts two jobs from the same crontab entry
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 1am. > > Our summer time just ended here. Might a similar shift have happened for you? Well, except that the format of the crontab is Minute Hour Day-of-Month . :-) -- The key to getting good answers is to ask good questions. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: Cron sometimes starts two jobs from the same crontab entry
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 similar shift have happened for you? Cheers, Cameron Simpson ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: Cron sometimes starts two jobs from the same crontab entry
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 identical start times occasionally. I have had to add a file lock system in the bbackup-beam to cope with this. Any idea on why cron might start the same job off twice at the same time ? Could there be a time change issue with chronyd ? Have you checked the logs to see when the jobs were started and if there are any relevant messages? ___ Yes, there is nothing unusual in /var/log/cron: /var/log/messages Are you not using the journal? ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: Cron sometimes starts two jobs from the same crontab entry
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:18 via enp4s0 [...] In the backup log: 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 at Mon 6 Apr 23:01:01 BST 2020 [...] Maybe irrelevant, but just mentioning: the log extract from /var/log/messages is dated Feb 24, whereas the other two are dated Apr 6. Best regards, Iosif Yes, missed that. I searched back for 23:01:00 and missed the fact that it was the wrong month. There was even less of interest in /var/log/messages around Apr 6 23:01:00, just some DHCP requests. Terry ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: Cron sometimes starts two jobs from the same crontab entry
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: 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 at Mon 6 Apr 23:01:01 BST 2020 [...] Maybe irrelevant, but just mentioning: the log extract from /var/log/messages is dated Feb 24, whereas the other two are dated Apr 6. Best regards, Iosif___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: Cron sometimes starts two jobs from the same crontab entry
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-twice I tend to believe it's not the cron entry by itself, but something n the environment. I'm curious what you'll find. Best rergards, Iosif ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: Cron sometimes starts two jobs from the same crontab entry
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 if this could happen and I have seen this issue about 4 times in a year, so it is not a totally sporadic event. grep-ing my /var/log/messages brings up entries like Apr 5 08:16:43 localhost chronyd[900]: System clock wrong by 1.516625 seconds, adjustment started Apr 5 08:16:43 localhost chronyd[900]: System clock was stepped by 1.516625 seconds Maybe you have some similar adjustements or bigger on the system? One second off hitting exactly the moment your crontab scripts start could be an explanation to 'double starts', although it seems rather improbable to have that happen that often. If you still have some logs around from the last time it happened, maybe you can check if there is a connection between such adjustemnts and the double-starters. Otherwise, checking if such adjustements are happening often per day or just once in weeks might be a next step to do in order to track down the issue. Best regards, Iosif ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: Cron sometimes starts two jobs from the same crontab entry
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 identical start times occasionally. I have had to add a file lock system in the bbackup-beam to cope with this. Any idea on why cron might start the same job off twice at the same time ? Could there be a time change issue with chronyd ? Have you checked the logs to see when the jobs were started and if there are any relevant messages? ___ Yes, there is nothing unusual in /var/log/cron: Apr 6 22:01:01 beam CROND[651585]: (root) CMD (run-parts /etc/cron.hourly) Apr 6 22:01:01 beam run-parts[651585]: (/etc/cron.hourly) starting 0anacron Apr 6 22:01:01 beam run-parts[651585]: (/etc/cron.hourly) finished 0anacron Apr 6 23:01:01 beam CROND[652722]: (root) CMD (/src/bbackup/bbackup-beam) Apr 6 23:01:01 beam CROND[652721]: (root) CMD (run-parts /etc/cron.hourly) Apr 6 23:01:01 beam run-parts[652721]: (/etc/cron.hourly) starting 0anacron Apr 6 23:01:01 beam CROND[652720]: (root) CMDOUT (Waking up 70:85:c2:0f:68:07...) Apr 6 23:01:01 beam run-parts[652721]: (/etc/cron.hourly) finished 0anacron Apr 6 23:01:21 beam CROND[652720]: (root) CMDOUT (Starting Backup) I do note that /etc/cron.hourly is performed at a minute past the hour as well though ... /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 Feb 24 23:00:03 beam dhcpd[1743]: DHCPACK on 192.168.201.214 to 00:25:b3:e6:a9:18 via enp4s0 Feb 24 23:00:05 beam systemd[1]: Starting system activity accounting tool... Feb 24 23:00:05 beam systemd[1]: sysstat-collect.service: Succeeded. Feb 24 23:00:05 beam systemd[1]: Started system activity accounting tool. Feb 24 23:00:05 beam audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=sysstat-collect comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Feb 24 23:00:05 beam audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=sysstat-collect comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Feb 24 23:00:41 beam dhcpd[1743]: DHCPREQUEST for 192.168.201.241 from 70:85:c2:0f:68:07 via enp4s0 Feb 24 23:00:41 beam dhcpd[1743]: DHCPACK on 192.168.201.241 to 70:85:c2:0f:68:07 via enp4s0 Feb 24 23:00:59 beam dhcpd[1743]: DHCPREQUEST for 192.168.201.26 from 84:1b:5e:70:2a:c9 via enp4s0 Feb 24 23:00:59 beam dhcpd[1743]: DHCPACK on 192.168.201.26 to 84:1b:5e:70:2a:c9 via enp4s0 Feb 24 23:01:01 beam dhcpd[1743]: DHCPREQUEST for 192.168.201.250 from 4c:60:de:e4:29:2d via enp4s0 Feb 24 23:01:01 beam dhcpd[1743]: DHCPACK on 192.168.201.250 to 4c:60:de:e4:29:2d via enp4s0 Feb 24 23:01:20 beam dhcpd[1743]: DHCPREQUEST for 192.168.201.28 from 00:50:c2:e2:f0:db via enp4s0 Feb 24 23:01:20 beam dhcpd[1743]: DHCPACK on 192.168.201.28 to 00:50:c2:e2:f0:db via enp4s0 Feb 24 23:01:32 beam dhcpd[1743]: DHCPREQUEST for 192.168.201.8 from 00:d8:61:a0:a4:06 via enp4s0 Feb 24 23:01:32 beam dhcpd[1743]: DHCPACK on 192.168.201.8 to 00:d8:61:a0:a4:06 via enp4s0 Feb 24 23:02:21 beam dhcpd[1743]: DHCPREQUEST for 192.168.201.214 from 00:25:b3:e6:a9:18 via enp4s0 Feb 24 23:02:21 beam dhcpd[1743]: DHCPACK on 192.168.201.214 to 00:25:b3:e6:a9:18 via enp4s0 Feb 24 23:03:10 beam dhcpd[1743]: DHCPREQUEST for 192.168.201.241 from 70:85:c2:0f:68:07 via enp4s0 In the backup log: 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 at Mon 6 Apr 23:01:01 BST 2020 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 at Mon 6 Apr 23:01:01 BST 2020 Backup aborted as locked by another backup Bbackup completed status: 0 at Tue 7 Apr 11:12:00 BST 2020 The bbackup-beam shell script is pretty basic and I can't see how this could have an issue like this. The same system has been running since 2009 without any issues. This problem started happening around Fedora27 or perhaps Fedora29 I think. Terry ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: Cron sometimes starts two jobs from the same crontab entry
On 07/04/2020 09:25, Iosif Fettich wrote: Hi, On 2020-04-07 14:07, Terry Barnaby wrote: I have a simple backup system that starts off a backup once per night during the weekdays. There is a crontab file in /etc/cron.d with the following entries: # Beam Bbackup cron setup Backup to ... # # Min Hour Day Month WeekDay # Perform incremental backup to every work day 01 23 * * 1 root /src/bbackup/bbackup-beam 01 23 * * 2 root /src/bbackup/bbackup-beam 01 23 * * 3 root /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 occasionally. I have had to add a file lock system in the bbackup-beam to cope with this. Any idea on why cron might start the same job off twice at the same time ? Could there be a time change issue with chronyd ? Are you sure that the jobs you saw started *twice*...? If one of the jobs would not finish till next launch time, maybe just hanging around due to some error, you'll end up with multiple jobs out there, despite the fact that they started days apart. Another possible issue might be the daylight saving time. If you're using a non-UTC timezone, there are datetimes that repeat or that are missing. 23:01 seems not to be among them, but what do I know... Same thing might happen if there are periodical bigger time adjustements (NTP, manual, ...). If it happens more than once that the system time is 23:01, launching the script each time is not only legit, but actually mandatory. Best regards, Iosif Fettich I am pretty sure two jobs are started at the same time. The backup script. that is run. writes some logging text to a log file with the datetime it started. I see two entries with the same datetime and without the file lock the backups get messed up due to two operating at once. This "fault" has happened about 4 times in the last year. 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 if this could happen and I have seen this issue about 4 times in a year, so it is not a totally sporadic event. Terry ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: Cron sometimes starts two jobs from the same crontab entry
Hi, On 2020-04-07 14:07, Terry Barnaby wrote: I have a simple backup system that starts off a backup once per night during the weekdays. There is a crontab file in /etc/cron.d with the following entries: # Beam Bbackup cron setup Backup to ... # # Min Hour Day Month WeekDay # Perform incremental backup to every work day 01 23 * * 1 root /src/bbackup/bbackup-beam 01 23 * * 2 root /src/bbackup/bbackup-beam 01 23 * * 3 root /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 occasionally. I have had to add a file lock system in the bbackup-beam to cope with this. Any idea on why cron might start the same job off twice at the same time ? Could there be a time change issue with chronyd ? Are you sure that the jobs you saw started *twice*...? If one of the jobs would not finish till next launch time, maybe just hanging around due to some error, you'll end up with multiple jobs out there, despite the fact that they started days apart. Another possible issue might be the daylight saving time. If you're using a non-UTC timezone, there are datetimes that repeat or that are missing. 23:01 seems not to be among them, but what do I know... Same thing might happen if there are periodical bigger time adjustements (NTP, manual, ...). If it happens more than once that the system time is 23:01, launching the script each time is not only legit, but actually mandatory. Best regards, Iosif Fettich___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: Cron sometimes starts two jobs from the same crontab entry
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 identical start times occasionally. I have had to add a file lock system in the bbackup-beam to cope with this. Any idea on why cron might start the same job off twice at the same time ? Could there be a time change issue with chronyd ? Have you checked the logs to see when the jobs were started and if there are any relevant messages? ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: Cron sometimes starts two jobs from the same crontab entry
On 07/04/2020 08:21, Ed Greshko wrote: On 2020-04-07 14:07, Terry Barnaby wrote: I have a simple backup system that starts off a backup once per night during the weekdays. There is a crontab file in /etc/cron.d with the following entries: # Beam Bbackup cron setup Backup to ... # # Min Hour Day Month WeekDay # Perform incremental backup to every work day 01 23 * * 1 root /src/bbackup/bbackup-beam 01 23 * * 2 root /src/bbackup/bbackup-beam 01 23 * * 3 root /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 occasionally. I have had to add a file lock system in the bbackup-beam to cope with this. Any idea on why cron might start the same job off twice at the same time ? Could there be a time change issue with chronyd ? I don't have an answer to your question. But wonder if using just 01 23 * * 1-5 root /src/bbackup/bbackup-beam would help avoid the problem. I assume the system is up 24/7? ___ Yes, server is up 24/7. Well I could try that, but I already have a workaround. The reason for asking is to find out if I am doing something wrong, if this is a known "feature" or is a bug in Fedora31. It could be a nasty little bug for some. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: Cron sometimes starts two jobs from the same crontab entry
On Tue, 2020-04-07 at 07:07 +0100, Terry Barnaby wrote: > I have had to add a file lock system in the bbackup-beam to cope with > this. Probably a good thing to do, anyway. -- uname -rsvp Linux 3.10.0-1062.18.1.el7.x86_64 #1 SMP Tue Mar 17 23:49:17 UTC 2020 x86_64 Boilerplate: All unexpected mail to my mailbox is automatically deleted. I will only get to see the messages that are posted to the mailing list. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: Cron sometimes starts two jobs from the same crontab entry
On 2020-04-07 14:07, Terry Barnaby wrote: > I have a simple backup system that starts off a backup once per night during > the weekdays. There is a crontab file in /etc/cron.d with the following > entries: > > > # Beam Bbackup cron setup Backup to ... > > # > # Min Hour Day Month WeekDay > > # Perform incremental backup to every work day > 01 23 * * 1 root /src/bbackup/bbackup-beam > 01 23 * * 2 root /src/bbackup/bbackup-beam > 01 23 * * 3 root /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 occasionally. > > I have had to add a file lock system in the bbackup-beam to cope with this. > > Any idea on why cron might start the same job off twice at the same time ? > Could there be a time change issue with chronyd ? > I don't have an answer to your question. But wonder if using just 01 23 * * 1-5 root /src/bbackup/bbackup-beam would help avoid the problem. I assume the system is up 24/7? ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Cron sometimes starts two jobs from the same crontab entry
I have a simple backup system that starts off a backup once per night during the weekdays. There is a crontab file in /etc/cron.d with the following entries: # Beam Bbackup cron setup Backup to ... # # Min Hour Day Month WeekDay # Perform incremental backup to every work day 01 23 * * 1 root /src/bbackup/bbackup-beam 01 23 * * 2 root /src/bbackup/bbackup-beam 01 23 * * 3 root /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 occasionally. I have had to add a file lock system in the bbackup-beam to cope with this. Any idea on why cron might start the same job off twice at the same time ? Could there be a time change issue with chronyd ? Terry ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: What cron entry generates mlocate.db ?
On 2019-12-10 07:25, Patrick O'Callaghan wrote: > On Mon, 2019-12-09 at 12:36 -0800, Jonathan Ryshpan wrote: >> It looks like mlocate.db is updated on command of systemd. >> >> I want to have updatedb create two databases, one indexing my backup >> device (/srv/UpdateDevice), which is a removable filesystem containing >> a complete backup of (the rest of) my system, and the other >> indexing the complete system, including the backup device. If >> mlocate.db were created via a cron command this would be easy. Since >> actually the command comes from systemd, which I'm not familiar with, >> it's not so easy. Any hints? > $ man updatedb > ... > EXAMPLES >To create a private mlocate database as an user other than root, run > updatedb -l 0 -o db_file -U source_directory > Right And for the process of updating the private database there is no reason why the OP can't use cron to do that. The current systemd process only updates the default database. The OP could also create their own systemd units. But I'm not certain that is what they would want to do. I don't think it would be that difficult. -- The key to getting good answers is to ask good questions. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: What cron entry generates mlocate.db ?
On Mon, 2019-12-09 at 12:36 -0800, Jonathan Ryshpan wrote: > It looks like mlocate.db is updated on command of systemd. > > I want to have updatedb create two databases, one indexing my backup > device (/srv/UpdateDevice), which is a removable filesystem containing > a complete backup of (the rest of) my system, and the other > indexing the complete system, including the backup device. If > mlocate.db were created via a cron command this would be easy. Since > actually the command comes from systemd, which I'm not familiar with, > it's not so easy. Any hints? $ man updatedb ... EXAMPLES To create a private mlocate database as an user other than root, run updatedb -l 0 -o db_file -U source_directory poc ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: What cron entry generates mlocate.db ?
It looks like mlocate.db is updated on command of systemd. I want to have updatedb create two databases, one indexing my backup device (/srv/UpdateDevice), which is a removable filesystem containing a complete backup of (the rest of) my system, and the other indexing the complete system, including the backup device. If mlocate.db were created via a cron command this would be easy. Since actually the command comes from systemd, which I'm not familiar with, it's not so easy. Any hints? Thanks - jon On Mon, 2019-12-09 at 16:51 +, Patrick O'Callaghan wrote: > On Mon, 2019-12-09 at 08:43 -0800, Jonathan Ryshpan wrote: > > I would have thought it's in /etc/cron.daily, but I can't find it. > > Where is it? > > $ man locatelocate reads one or more databases prepared by > updatedb(8) ... > $ man updatedb...updatedb is usually run daily by cron(8) to update > the default database > $ sudo find /etc|grep > updatedb/etc/updatedb.conf/etc/systemd/system/timers.target.wants/mlo > cate-updatedb.timer ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
