[opensuse] logrotate
Hi list, looking through my disk usage I realized /var/log uses 2GB :o and what do I see? woodstock:/var/log # ls -lh zypper.log -rw-r----- 1 root root 1.6G Sep 13 14:23 zypper.log why isn't it rotated/compressed? Ah: this is now handled by systemd instead of cron, and disabled by default :( woodstock:/var/log # systemctl status logrotate ● logrotate.service - Rotate log files Loaded: loaded (/usr/lib/systemd/system/logrotate.service; static; vendor preset: disabled) Not sure if that is a sane choice for a TW system that typically has several 'zypper dup' per week. The 1.6GB is the logs from just one year... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
* Peter Suetterlin <P.Suetterlin@royac.iac.es> [09-13-17 09:49]:
Hi list,
looking through my disk usage I realized /var/log uses 2GB :o and what do I see?
woodstock:/var/log # ls -lh zypper.log -rw-r----- 1 root root 1.6G Sep 13 14:23 zypper.log
why isn't it rotated/compressed? Ah: this is now handled by systemd instead of cron, and disabled by default :(
woodstock:/var/log # systemctl status logrotate ● logrotate.service - Rotate log files Loaded: loaded (/usr/lib/systemd/system/logrotate.service; static; vendor preset: disabled)
Not sure if that is a sane choice for a TW system that typically has several 'zypper dup' per week. The 1.6GB is the logs from just one year...
your Tw seems different than mine. all 5 of mine show: ● logrotate.service - Rotate log files Loaded: loaded (/usr/lib/systemd/system/logrotate.service; static; vendor preset: disabled) Active: inactive (dead) since Wed 2017-09-13 00:01:22 EDT; 10h ago Docs: man:logrotate(8) man:logrotate.conf(5) Process: 18438 ExecStart=/usr/sbin/logrotate /etc/logrotate.conf (code=exited, status=0/SUCCESS) Main PID: 18438 (code=exited, status=0/SUCCESS) logrotate is instigated by cron here. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Andrei Borzenkov wrote:
On Wed, Sep 13, 2017 at 5:15 PM, Patrick Shanahan <paka@opensuse.org> wrote:
logrotate is instigated by cron here.
It's not mentioned in any of the cron configs...
More likely by logrotate.timer.
woodstock:/etc # systemctl status logrotate.timer ● logrotate.timer - Daily rotation of log files Loaded: loaded (/usr/lib/systemd/system/logrotate.timer; disabled; vendor preset: enabled) Active: inactive (dead) Hmm, I can't remember having disabled it. But obviously my fault then :( -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Peter Suetterlin wrote:
Andrei Borzenkov wrote:
On Wed, Sep 13, 2017 at 5:15 PM, Patrick Shanahan <paka@opensuse.org> wrote:
logrotate is instigated by cron here.
It's not mentioned in any of the cron configs...
More likely by logrotate.timer.
woodstock:/etc # systemctl status logrotate.timer ● logrotate.timer - Daily rotation of log files Loaded: loaded (/usr/lib/systemd/system/logrotate.timer; disabled; vendor preset: enabled) Active: inactive (dead)
Hmm, I can't remember having disabled it. But obviously my fault then :(
I am pretty certain I've come across this too - yep: https://bugzilla.opensuse.org/show_bug.cgi?id=1054353 -- Per Jessen, Zürich (19.1°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Per Jessen composed on 2017-09-13 18:30 (UTC+0200):
Infuriatingly dup'd to an inaccessible bug: https://bugzilla.opensuse.org/show_bug.cgi?id=1051019 -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Felix Miata wrote:
Per Jessen composed on 2017-09-13 18:30 (UTC+0200):
Infuriatingly dup'd to an inaccessible bug: https://bugzilla.opensuse.org/show_bug.cgi?id=1051019
Well, the problem is very clearly identified and also easily solved. Dup'ing to an SLE bug is not such a big deal here, IMO. How did you fare with the hurricane, Felix? -- Per Jessen, Zürich (15.2°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Per Jessen wrote:
Peter Suetterlin wrote:
woodstock:/etc # systemctl status logrotate.timer ● logrotate.timer - Daily rotation of log files Loaded: loaded (/usr/lib/systemd/system/logrotate.timer; disabled; vendor preset: enabled) Active: inactive (dead)
Hmm, I can't remember having disabled it. But obviously my fault then :(
I am pretty certain I've come across this too - yep:
Ah. But all those bugs are about updates. My TW was a clean install from scratch. So the question would be if the timer is active on (all) other TW installations, or not. But I assume the (missing) activation would also fail when fresh installing? For now I manually did the suggested systemctl enable logrotate.timer systemctl start logrotate.timer and now get woodstock:/var/log # systemctl list-timers NEXT LEFT LAST PASSED UNIT ACTIVATES Thu 2017-09-14 10:48:57 WEST 1min 46s left Wed 2017-09-13 10:48:57 WEST 23h ago systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service Fri 2017-09-15 00:00:00 WEST 13h left n/a n/a logrotate.timer logrotate.service 2 timers listed. Guess next night will see quite some CPU cycles burnt, xz compressing some 1.6GB... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
* Patrick Shanahan <paka@opensuse.org> [09-13-17 10:15]:
* Peter Suetterlin <P.Suetterlin@royac.iac.es> [09-13-17 09:49]:
Hi list,
looking through my disk usage I realized /var/log uses 2GB :o and what do I see?
woodstock:/var/log # ls -lh zypper.log -rw-r----- 1 root root 1.6G Sep 13 14:23 zypper.log
why isn't it rotated/compressed? Ah: this is now handled by systemd instead of cron, and disabled by default :(
woodstock:/var/log # systemctl status logrotate ● logrotate.service - Rotate log files Loaded: loaded (/usr/lib/systemd/system/logrotate.service; static; vendor preset: disabled)
Not sure if that is a sane choice for a TW system that typically has several 'zypper dup' per week. The 1.6GB is the logs from just one year...
your Tw seems different than mine. all 5 of mine show: ● logrotate.service - Rotate log files Loaded: loaded (/usr/lib/systemd/system/logrotate.service; static; vendor preset: disabled) Active: inactive (dead) since Wed 2017-09-13 00:01:22 EDT; 10h ago Docs: man:logrotate(8) man:logrotate.conf(5) Process: 18438 ExecStart=/usr/sbin/logrotate /etc/logrotate.conf (code=exited, status=0/SUCCESS) Main PID: 18438 (code=exited, status=0/SUCCESS)
logrotate is instigated by cron here.
or maybe systemd timers ... -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Wed, Sep 13, 2017 at 9:48 AM, Peter Suetterlin <P.Suetterlin@royac.iac.es> wrote:
Hi list,
looking through my disk usage I realized /var/log uses 2GB :o and what do I see?
woodstock:/var/log # ls -lh zypper.log -rw-r----- 1 root root 1.6G Sep 13 14:23 zypper.log
why isn't it rotated/compressed? Ah: this is now handled by systemd instead of cron, and disabled by default :(
woodstock:/var/log # systemctl status logrotate ● logrotate.service - Rotate log files Loaded: loaded (/usr/lib/systemd/system/logrotate.service; static; vendor preset: disabled)
Not sure if that is a sane choice for a TW system that typically has several 'zypper dup' per week. The 1.6GB is the logs from just one year...
I don't think its by design. Various bugs reported about it. Here's mine from my 13.1 to 13.2 upgrade: https://bugzilla.novell.com/show_bug.cgi?id=913421 I didn't look to see if there is a bug against Tumbleweed or not. Greg -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 13/09/17 22:14, Greg Freemyer wrote:
On Wed, Sep 13, 2017 at 9:48 AM, Peter Suetterlin <P.Suetterlin@royac.iac.es> wrote:
Hi list,
looking through my disk usage I realized /var/log uses 2GB :o and what do I see?
woodstock:/var/log # ls -lh zypper.log -rw-r----- 1 root root 1.6G Sep 13 14:23 zypper.log
why isn't it rotated/compressed? Ah: this is now handled by systemd instead of cron, and disabled by default :(
woodstock:/var/log # systemctl status logrotate ● logrotate.service - Rotate log files Loaded: loaded (/usr/lib/systemd/system/logrotate.service; static; vendor preset: disabled)
Not sure if that is a sane choice for a TW system that typically has several 'zypper dup' per week. The 1.6GB is the logs from just one year...
I don't think its by design. Various bugs reported about it.
Here's mine from my 13.1 to 13.2 upgrade:
https://bugzilla.novell.com/show_bug.cgi?id=913421
I didn't look to see if there is a bug against Tumbleweed or not.
Greg
I'm confused. I have a fresh 42.2 installation which has systemd 228. If this was supposed to be enabled on an upgrade from 13.1 to 13.2, shouldn't all this be enabled by default on 42.2? I get the following:
systemctl list-timers NEXT LEFT LAST PASSED Fri 2017-09-15 08:35:50 CEST 18h left Wed 2017-09-13 12:42:59 CEST 1 day 1h ago Mon 2017-09-18 00:00:00 CEST 3 days left Mon 2017-09-11 00:00:01 CEST 3 days ago
2 timers listed. Pass --all to see loaded but inactive timers, too.
systemctl enable logrotate.timer Failed to execute operation: No such file or directory
systemctl status logrotate.service ● logrotate.service Loaded: not-found (Reason: No such file or directory) Active: inactive (dead)
I notice /var/log/journal/{string}/ has nearly 1GB of logs in it, going back as far as installation time. gumb -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
gumb wrote:
systemctl enable logrotate.timer Failed to execute operation: No such file or directory
systemctl status logrotate.service ● logrotate.service Loaded: not-found (Reason: No such file or directory) Active: inactive (dead)
I notice /var/log/journal/{string}/ has nearly 1GB of logs in it, going back as far as installation time.
Do you have logrotate installed? (it doesn't look like it).
From a 13.2 system:
# systemctl status logrotate.service logrotate.service - Rotate log files Loaded: loaded (/usr/lib/systemd/system/logrotate.service; static) Active: inactive (dead) Docs: man:logrotate(8) man:logrotate.conf(5) -- Per Jessen, Zürich (13.4°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 14/09/17 14:37, Per Jessen wrote:
gumb wrote:
systemctl enable logrotate.timer Failed to execute operation: No such file or directory
systemctl status logrotate.service ● logrotate.service Loaded: not-found (Reason: No such file or directory) Active: inactive (dead)
I notice /var/log/journal/{string}/ has nearly 1GB of logs in it, going back as far as installation time.
Do you have logrotate installed? (it doesn't look like it).
From a 13.2 system:
# systemctl status logrotate.service logrotate.service - Rotate log files Loaded: loaded (/usr/lib/systemd/system/logrotate.service; static) Active: inactive (dead) Docs: man:logrotate(8) man:logrotate.conf(5)
Yes it appears to be installed. logrotate --version logrotate 3.8.7 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
gumb wrote:
On 14/09/17 14:37, Per Jessen wrote:
gumb wrote:
systemctl enable logrotate.timer Failed to execute operation: No such file or directory
systemctl status logrotate.service ● logrotate.service Loaded: not-found (Reason: No such file or directory) Active: inactive (dead)
I notice /var/log/journal/{string}/ has nearly 1GB of logs in it, going back as far as installation time.
Do you have logrotate installed? (it doesn't look like it).
From a 13.2 system:
# systemctl status logrotate.service logrotate.service - Rotate log files Loaded: loaded (/usr/lib/systemd/system/logrotate.service; static) Active: inactive (dead) Docs: man:logrotate(8) man:logrotate.conf(5)
Yes it appears to be installed.
logrotate --version logrotate 3.8.7
My mistake, I thought logrotate was already a systemd service, but just still being called with cron. -- Per Jessen, Zürich (14.1°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-09-14 14:37, Per Jessen wrote:
gumb wrote:
systemctl enable logrotate.timer Failed to execute operation: No such file or directory
systemctl status logrotate.service ● logrotate.service Loaded: not-found (Reason: No such file or directory) Active: inactive (dead)
I notice /var/log/journal/{string}/ has nearly 1GB of logs in it, going back as far as installation time.
Do you have logrotate installed? (it doesn't look like it).
Leap uses cron. /etc/cron.daily/logrotate -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
On 14/09/17 15:12, Carlos E. R. wrote:
On 2017-09-14 14:37, Per Jessen wrote:
gumb wrote:
systemctl enable logrotate.timer Failed to execute operation: No such file or directory
systemctl status logrotate.service ● logrotate.service Loaded: not-found (Reason: No such file or directory) Active: inactive (dead)
I notice /var/log/journal/{string}/ has nearly 1GB of logs in it, going back as far as installation time.
Do you have logrotate installed? (it doesn't look like it).
Leap uses cron.
/etc/cron.daily/logrotate
Okay, I misunderstood. I saw the systemd journal logs building up and assumed something wasn't running as intended, but you explained in the other post that that's handled differently. What is confusing is that, if I'm understanding the thread correctly, this change to systemd logs was introduced in 13.2, and is posing problems for those upgrading from, say, 13.1 to 13.2 or from 42.2 to 42.3, yet the new logs handling is not present in a fresh Leap 42.1 or 42.2 install. Is this one of those cases where Leap 42.1 was not a progression from 13.2, because it went back to an old version/system so as to align with SUSE 12? And is it now being introduced in Leap 42.3? gumb -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
gumb wrote:
What is confusing is that, if I'm understanding the thread correctly, this change to systemd logs was introduced in 13.2, and is posing problems for those upgrading from, say, 13.1 to 13.2
It look like logrotate was upgraded to a systemd service in 13.2, as well as equipped with a systemd timer instead of being driven by cron.
or from 42.2 to 42.3, yet the new logs handling is not present in a fresh Leap 42.1 or 42.2 install.
The only thing that is missing is for the timer to be enabled.
Is this one of those cases where Leap 42.1 was not a progression from 13.2, because it went back to an old version/system so as to align with SUSE 12?
Quite likely yes.
And is it now being introduced in Leap 42.3?
In Leap423, logrotate was updated to use a systemd timer instead of cron, yes. -- Per Jessen, Zürich (14.3°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-09-14 15:42, Per Jessen wrote:
gumb wrote:
What is confusing is that, if I'm understanding the thread correctly, this change to systemd logs was introduced in 13.2, and is posing problems for those upgrading from, say, 13.1 to 13.2
It look like logrotate was upgraded to a systemd service in 13.2, as well as equipped with a systemd timer instead of being driven by cron.
or from 42.2 to 42.3, yet the new logs handling is not present in a fresh Leap 42.1 or 42.2 install.
The only thing that is missing is for the timer to be enabled.
Is this one of those cases where Leap 42.1 was not a progression from 13.2, because it went back to an old version/system so as to align with SUSE 12?
Quite likely yes.
And is it now being introduced in Leap 42.3?
In Leap423, logrotate was updated to use a systemd timer instead of cron, yes.
I don't like that. Less visible. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
Carlos E. R. wrote:
On 2017-09-14 15:42, Per Jessen wrote:
gumb wrote:
What is confusing is that, if I'm understanding the thread correctly, this change to systemd logs was introduced in 13.2, and is posing problems for those upgrading from, say, 13.1 to 13.2
It look like logrotate was upgraded to a systemd service in 13.2, as well as equipped with a systemd timer instead of being driven by cron.
or from 42.2 to 42.3, yet the new logs handling is not present in a fresh Leap 42.1 or 42.2 install.
The only thing that is missing is for the timer to be enabled.
Is this one of those cases where Leap 42.1 was not a progression from 13.2, because it went back to an old version/system so as to align with SUSE 12?
Quite likely yes.
And is it now being introduced in Leap 42.3?
In Leap423, logrotate was updated to use a systemd timer instead of cron, yes.
I don't like that. Less visible.
Yes, I'm not very fond of it nor do I see any advantage in it either. -- Per Jessen, Zürich (13.9°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
* Carlos E. R. <robin.listas@telefonica.net> [09-14-17 10:51]:
On 2017-09-14 15:42, Per Jessen wrote:
gumb wrote:
What is confusing is that, if I'm understanding the thread correctly, this change to systemd logs was introduced in 13.2, and is posing problems for those upgrading from, say, 13.1 to 13.2
It look like logrotate was upgraded to a systemd service in 13.2, as well as equipped with a systemd timer instead of being driven by cron.
or from 42.2 to 42.3, yet the new logs handling is not present in a fresh Leap 42.1 or 42.2 install.
The only thing that is missing is for the timer to be enabled.
Is this one of those cases where Leap 42.1 was not a progression from 13.2, because it went back to an old version/system so as to align with SUSE 12?
Quite likely yes.
And is it now being introduced in Leap 42.3?
In Leap423, logrotate was updated to use a systemd timer instead of cron, yes.
I don't like that. Less visible.
add an email notice to the particular script(s) -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-09-14 16:55, Patrick Shanahan wrote:
* Carlos E. R. <robin.listas@telefonica.net> [09-14-17 10:51]:
On 2017-09-14 15:42, Per Jessen wrote:
gumb wrote:
What is confusing is that, if I'm understanding the thread correctly, this change to systemd logs was introduced in 13.2, and is posing problems for those upgrading from, say, 13.1 to 13.2
It look like logrotate was upgraded to a systemd service in 13.2, as well as equipped with a systemd timer instead of being driven by cron.
or from 42.2 to 42.3, yet the new logs handling is not present in a fresh Leap 42.1 or 42.2 install.
The only thing that is missing is for the timer to be enabled.
Is this one of those cases where Leap 42.1 was not a progression from 13.2, because it went back to an old version/system so as to align with SUSE 12?
Quite likely yes.
And is it now being introduced in Leap 42.3?
In Leap423, logrotate was updated to use a systemd timer instead of cron, yes.
I don't like that. Less visible.
add an email notice to the particular script(s)
To see that it has run? I don't mean that. With cron, I just have to list the directory and know what should run instantly. I don't have to learn new commands to find out. If there is some advantage, well, fine, but I don't see them. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
14.09.2017 21:19, Carlos E. R. пишет:
With cron, I just have to list the directory and know what should run instantly.
That has never been true, even less on (open)SUSE. cron can execute arbitrary command that itself can gather further scripts to execute from elsewhere. In particular, you have at least /etc/cron.{hourly,daily,weekly} that do not follow normal cron file format, so you need to look elsewhere to just find out when these are run. Then there is /etc/cron.d which again deviates from standard cron file format.
I don't have to learn new commands to find out.
You have if you want to actually understand how cron on SUSE works.
Andrei Borzenkov wrote:
14.09.2017 21:19, Carlos E. R. пишет:
With cron, I just have to list the directory and know what should run instantly.
That has never been true, even less on (open)SUSE. cron can execute arbitrary command that itself can gather further scripts to execute from elsewhere.
So not so different from a systemd service unit. I like being to get a quick overview or what runs when: cat /etc/crontab /etc/cron.d/*
In particular, you have at least /etc/cron.{hourly,daily,weekly} that do not follow normal cron file format, so you need to look elsewhere to just find out when these are run.
Yeah. I was never a friend of that idea.
Then there is /etc/cron.d which again deviates from standard cron file format.
Oh, I wasn't aware. (it's been the standard format for me since forever :-) ) -- Per Jessen, Zürich (8.7°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Fri, Sep 15, 2017 at 9:10 AM, Per Jessen <per@computer.org> wrote:
Andrei Borzenkov wrote:
14.09.2017 21:19, Carlos E. R. пишет:
With cron, I just have to list the directory and know what should run instantly.
That has never been true, even less on (open)SUSE. cron can execute arbitrary command that itself can gather further scripts to execute from elsewhere.
So not so different from a systemd service unit.
I like being to get a quick overview or what runs when:
cat /etc/crontab /etc/cron.d/*
there is also /var/spool/cron/tabs ...
In particular, you have at least /etc/cron.{hourly,daily,weekly} that do not follow normal cron file format, so you need to look elsewhere to just find out when these are run.
Yeah. I was never a friend of that idea.
Then there is /etc/cron.d which again deviates from standard cron file format.
Oh, I wasn't aware. (it's been the standard format for me since forever :-) )
Historical crontab format does not include user name (because it was by definition per-user), while /etc/cron.d inserts one more field with it. So they are not directly interchangeable. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Andrei Borzenkov wrote:
On Fri, Sep 15, 2017 at 9:10 AM, Per Jessen <per@computer.org> wrote:
Andrei Borzenkov wrote:
14.09.2017 21:19, Carlos E. R. пишет:
With cron, I just have to list the directory and know what should run instantly.
That has never been true, even less on (open)SUSE. cron can execute arbitrary command that itself can gather further scripts to execute from elsewhere.
So not so different from a systemd service unit.
I like being to get a quick overview or what runs when:
cat /etc/crontab /etc/cron.d/*
there is also /var/spool/cron/tabs ...
Right, but from an admin perspective, I'm not so interested in the user tabs - except when backing up. In fact, I think they're in the wrong place - they ought to be in ~/crontab (or something similar). Of course, that might make them run on multiple machines (nfs-mounted /home).
Historical crontab format does not include user name (because it was by definition per-user), while /etc/cron.d inserts one more field with it. So they are not directly interchangeable.
Aha, thanks for explaining that. -- Per Jessen, Zürich (11.9°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 15/09/17 10:03, Per Jessen wrote:
In fact, I think they're in the wrong place - they ought to be in ~/crontab (or something similar).
imho, we ought to have ~/.etc (or ~/etc), and all those damn dotfiles could just go in there rather than cluttering up ~/ :-) Windows does that sort of thing, and while I may not be a fan of it, it's a lot better than the current mess. Cheers, Wol -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 16/09/17 07:55 AM, Wols Lists wrote:
On 15/09/17 10:03, Per Jessen wrote:
In fact, I think they're in the wrong place - they ought to be in ~/crontab (or something similar).
+1
imho, we ought to have ~/.etc (or ~/etc), and all those damn dotfiles could just go in there rather than cluttering up ~/ :-)
+1 Yes we could link but that doesn't clear up the mess. How many here remember what it was like in the days before the "Great /etc/ Rationalization", when the config files we have there now were scattered, ad-hoc, though the file system? You might hear my reminiscing about "The Old Days", but they are really there to learn from, not, despite what some politicians might make an emotional appeal for, to return to. That loads offtopic.... -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
15.09.2017 12:03, Per Jessen пишет:
there is also /var/spool/cron/tabs ...
Right, but from an admin perspective, I'm not so interested in the user tabs - except when backing up. In fact, I think they're in the wrong place - they ought to be in ~/crontab (or something similar).
Now let's take a system with several thousands users with NFS mounted home directories. Do you seriously suggest that crond must scan all of them every minute to find out whether ~/crontab changed? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Op zaterdag 16 september 2017 15:18:50 CEST schreef Andrei Borzenkov:
15.09.2017 12:03, Per Jessen пишет:
there is also /var/spool/cron/tabs ...
Right, but from an admin perspective, I'm not so interested in the user tabs - except when backing up. In fact, I think they're in the wrong place - they ought to be in ~/crontab (or something similar).
Now let's take a system with several thousands users with NFS mounted home directories. Do you seriously suggest that crond must scan all of them every minute to find out whether ~/crontab changed?
Exactly.. Not me. Certainly not when we have such beautiful tools available like saltstack. -- Gertjan Lettink, a.k.a. Knurpht openSUSE Board Member openSUSE Forums Team -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Knurpht - Gertjan Lettink wrote:
Op zaterdag 16 september 2017 15:18:50 CEST schreef Andrei Borzenkov:
15.09.2017 12:03, Per Jessen пишет:
there is also /var/spool/cron/tabs ...
Right, but from an admin perspective, I'm not so interested in the user tabs - except when backing up. In fact, I think they're in the wrong place - they ought to be in ~/crontab (or something similar).
Now let's take a system with several thousands users with NFS mounted home directories. Do you seriously suggest that crond must scan all of them every minute to find out whether ~/crontab changed?
Exactly.. Not me. Certainly not when we have such beautiful tools available like saltstack.
Okay, you got me curious - what does saltstack have to do with user crontabs ? -- Per Jessen, Zürich (14.9°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Op zaterdag 16 september 2017 17:35:44 CEST schreef Per Jessen:
Knurpht - Gertjan Lettink wrote:
Op zaterdag 16 september 2017 15:18:50 CEST schreef Andrei Borzenkov:
15.09.2017 12:03, Per Jessen пишет:
there is also /var/spool/cron/tabs ...
Right, but from an admin perspective, I'm not so interested in the user tabs - except when backing up. In fact, I think they're in the wrong place - they ought to be in ~/crontab (or something similar).
Now let's take a system with several thousands users with NFS mounted home directories. Do you seriously suggest that crond must scan all of them every minute to find out whether ~/crontab changed?
Exactly.. Not me. Certainly not when we have such beautiful tools available like saltstack.
Okay, you got me curious - what does saltstack have to do with user crontabs ? Allows you to have one single timer of cronjob in one place to take care of a whole bunch of machines etc. etc. My private setup triggers a pkg.upgrade on all minions f.e. So no cron jobs per machine/user, just one job handled by salt. A timer could easily have this done over night,. The example may not be the perfect one, but there's lots more salt can handle from one central point.
-- Gertjan Lettink, a.k.a. Knurpht openSUSE Board Member openSUSE Forums Team -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Knurpht - Gertjan Lettink wrote:
Op zaterdag 16 september 2017 17:35:44 CEST schreef Per Jessen:
Knurpht - Gertjan Lettink wrote:
Op zaterdag 16 september 2017 15:18:50 CEST schreef Andrei Borzenkov:
15.09.2017 12:03, Per Jessen пишет:
there is also /var/spool/cron/tabs ...
Right, but from an admin perspective, I'm not so interested in the user tabs - except when backing up. In fact, I think they're in the wrong place - they ought to be in ~/crontab (or something similar).
Now let's take a system with several thousands users with NFS mounted home directories. Do you seriously suggest that crond must scan all of them every minute to find out whether ~/crontab changed?
Exactly.. Not me. Certainly not when we have such beautiful tools available like saltstack.
Okay, you got me curious - what does saltstack have to do with user crontabs ?
Allows you to have one single timer of cronjob in one place to take care of a whole bunch of machines etc. etc.
Maybe a terminology issue, but user != admin ? To me a user might log in from multiple machines/desktops, but usually doesn't do any admin. Typically their cronjobs control what happens on their "own" desktop.
My private setup triggers a pkg.upgrade on all minions f.e. So no cron jobs per machine/user, just one job handled by salt. A timer could easily have this done over night,. The example may not be the perfect one, but there's lots more salt can handle from one central point.
Sure, I just don't really make the connection to user cronjobs. I must be missing something. -- Per Jessen, Zürich (13.1°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Andrei Borzenkov wrote:
15.09.2017 12:03, Per Jessen пишет:
there is also /var/spool/cron/tabs ...
Right, but from an admin perspective, I'm not so interested in the user tabs - except when backing up. In fact, I think they're in the wrong place - they ought to be in ~/crontab (or something similar).
Now let's take a system with several thousands users with NFS mounted home directories. Do you seriously suggest that crond must scan all of them every minute to find out whether ~/crontab changed?
I did touch on NFS-mounted /home later that post, and I agree it is not useful in that situation. OTOH, having user-specific data outside /home can also be a bit of a pain. -- Per Jessen, Zürich (15.1°C) http://www.cloudsuisse.com/ - your owncloud, hosted in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
16.09.2017 18:35, Per Jessen пишет:
Andrei Borzenkov wrote:
15.09.2017 12:03, Per Jessen пишет:
there is also /var/spool/cron/tabs ...
Right, but from an admin perspective, I'm not so interested in the user tabs - except when backing up. In fact, I think they're in the wrong place - they ought to be in ~/crontab (or something similar).
Now let's take a system with several thousands users with NFS mounted home directories. Do you seriously suggest that crond must scan all of them every minute to find out whether ~/crontab changed?
I did touch on NFS-mounted /home later that post, and I agree it is not useful in that situation. OTOH, having user-specific data outside /home can also be a bit of a pain.
Arguably this is not "user specific data" but rather "system data with fine grained access control". To this extent one could say that NetworkManager system connection is user data because user on local console is allowed to edit it by appropriate policy kit configuration. Although distinction is rather blurry indeed. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Andrei Borzenkov wrote:
16.09.2017 18:35, Per Jessen пишет:
Andrei Borzenkov wrote:
15.09.2017 12:03, Per Jessen пишет:
there is also /var/spool/cron/tabs ...
Right, but from an admin perspective, I'm not so interested in the user tabs - except when backing up. In fact, I think they're in the wrong place - they ought to be in ~/crontab (or something similar).
Now let's take a system with several thousands users with NFS mounted home directories. Do you seriously suggest that crond must scan all of them every minute to find out whether ~/crontab changed?
I did touch on NFS-mounted /home later that post, and I agree it is not useful in that situation. OTOH, having user-specific data outside /home can also be a bit of a pain.
Arguably this is not "user specific data" but rather "system data with fine grained access control".
Hmm, not sure about that one. I know that is how it is currently maintained, but from a user perspective, the cronjobs are as specific as are her email accounts. One job I run from my user crontab is every 10min to update my email signature with the current outdoor temperature. Not sure why anyone would think that is system data :-)
To this extent one could say that NetworkManager system connection is user data because user on local console is allowed to edit it by appropriate policy kit configuration.
Good example.
Although distinction is rather blurry indeed.
Yeah. -- Per Jessen, Zürich (10.9°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-09-16 17:35, Per Jessen wrote:
Andrei Borzenkov wrote:
15.09.2017 12:03, Per Jessen пишет:
there is also /var/spool/cron/tabs ...
Right, but from an admin perspective, I'm not so interested in the user tabs - except when backing up. In fact, I think they're in the wrong place - they ought to be in ~/crontab (or something similar).
Now let's take a system with several thousands users with NFS mounted home directories. Do you seriously suggest that crond must scan all of them every minute to find out whether ~/crontab changed?
I did touch on NFS-mounted /home later that post, and I agree it is not useful in that situation. OTOH, having user-specific data outside /home can also be a bit of a pain.
But in the case of users cronjobs makes a lot of sense: all are in a single directory, thus keeping track of which file has changed every minute (cron does that) is easy to do. On the other hand, when one such job runs, maybe the home is not mounted. Per user systemd timers reside on home. How does systemd track the situation? Well, I think systemd is not aware of a change unless you tell it to read the files again, so it does not matter where they reside. Of course, the mount must be active. I suppose it might also mount the home automatically prior to running the job? No way the job itself can do that. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith))
Carlos E. R. wrote:
On 2017-09-16 17:35, Per Jessen wrote:
Andrei Borzenkov wrote:
15.09.2017 12:03, Per Jessen пишет:
there is also /var/spool/cron/tabs ...
Right, but from an admin perspective, I'm not so interested in the user tabs - except when backing up. In fact, I think they're in the wrong place - they ought to be in ~/crontab (or something similar).
Now let's take a system with several thousands users with NFS mounted home directories. Do you seriously suggest that crond must scan all of them every minute to find out whether ~/crontab changed?
I did touch on NFS-mounted /home later that post, and I agree it is not useful in that situation. OTOH, having user-specific data outside /home can also be a bit of a pain.
But in the case of users cronjobs makes a lot of sense: all are in a single directory, thus keeping track of which file has changed every minute (cron does that) is easy to do. On the other hand, when one such job runs, maybe the home is not mounted.
Keeping track of changes on the local filesystem is not a problem, cron uses inotify. I don't think keeping user-specific settings outside /home for that reason makes much sense. Anyway, I wasn't after a prolonged debate, I only mentioned user cronjobs, because I've been bitten more than once when installing a new machine, moving a user, restoring a backup etc etc.
Per user systemd timers reside on home. How does systemd track the situation? Well, I think systemd is not aware of a change unless you tell it to read the files again, so it does not matter where they reside. Of course, the mount must be active. I suppose it might also mount the home automatically prior to running the job? No way the job itself can do that.
I'm not sure what it is you need mounted (/home ?), but (systemd-)automount can take care of it. -- Per Jessen, Zürich (10.9°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-09-17 10:01, Per Jessen wrote:
Carlos E. R. wrote:
On 2017-09-16 17:35, Per Jessen wrote:
Andrei Borzenkov wrote:
15.09.2017 12:03, Per Jessen пишет:
there is also /var/spool/cron/tabs ...
Right, but from an admin perspective, I'm not so interested in the user tabs - except when backing up. In fact, I think they're in the wrong place - they ought to be in ~/crontab (or something similar).
Now let's take a system with several thousands users with NFS mounted home directories. Do you seriously suggest that crond must scan all of them every minute to find out whether ~/crontab changed?
I did touch on NFS-mounted /home later that post, and I agree it is not useful in that situation. OTOH, having user-specific data outside /home can also be a bit of a pain.
But in the case of users cronjobs makes a lot of sense: all are in a single directory, thus keeping track of which file has changed every minute (cron does that) is easy to do. On the other hand, when one such job runs, maybe the home is not mounted.
Keeping track of changes on the local filesystem is not a problem, cron uses inotify. I don't think keeping user-specific settings outside /home for that reason makes much sense. Anyway, I wasn't after a prolonged debate, I only mentioned user cronjobs, because I've been bitten more than once when installing a new machine, moving a user, restoring a backup etc etc.
I'm simply curious :-) But there are several things that store user files under /var. There is mail (possibly), faxes, crontabs, and I don't remember what.
Per user systemd timers reside on home. How does systemd track the situation? Well, I think systemd is not aware of a change unless you tell it to read the files again, so it does not matter where they reside. Of course, the mount must be active. I suppose it might also mount the home automatically prior to running the job? No way the job itself can do that.
I'm not sure what it is you need mounted (/home ?), but (systemd-)automount can take care of it.
I was wondering aloud about what happens when a user has timers enabled. Does it automatically mount home in time for the timer to run? -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
Carlos E. R. wrote:
But there are several things that store user files under /var. There is mail (possibly), faxes, crontabs, and I don't remember what.
I see postfix also uses /var/mail by default - not a good default, I would say, but I've been running a separate mailserver for so long.
Per user systemd timers reside on home. How does systemd track the situation? Well, I think systemd is not aware of a change unless you tell it to read the files again, so it does not matter where they reside. Of course, the mount must be active. I suppose it might also mount the home automatically prior to running the job? No way the job itself can do that.
I'm not sure what it is you need mounted (/home ?), but (systemd-)automount can take care of it.
I was wondering aloud about what happens when a user has timers enabled. Does it automatically mount home in time for the timer to run?
Once the timer fires and systemd-user tries to access whatever the service unit needs, it would be mounted. -- Per Jessen, Zürich (15.1°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-09-15 05:24, Andrei Borzenkov wrote:
14.09.2017 21:19, Carlos E. R. пишет:
With cron, I just have to list the directory and know what should run instantly.
That has never been true, even less on (open)SUSE. cron can execute arbitrary command that itself can gather further scripts to execute from elsewhere. In particular, you have at least /etc/cron.{hourly,daily,weekly} that do not follow normal cron file format, so you need to look elsewhere to just find out when these are run. Then there is /etc/cron.d which again deviates from standard cron file format.
No, this is not correct. It follows the documented format (there are two in openSUSE). "man 5 crontab" The files in /etc/cron.d have an extra field for the username. The files in /etc/cron.{hourly,daily,weekly,monthly} are run by /usr/lib/cron/run-crons, from /etc/crontab.
I don't have to learn new commands to find out.
You have if you want to actually understand how cron on SUSE works.
I understand how cron on SUSE works, since decades ago. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
On 09/15/2017 04:04 AM, Carlos E. R. wrote:
I understand how cron on SUSE works, since decades ago.
Not me. I've had to read the man page or work from a template every time I wanted to do anything with Crontab. It was obtuse as hell the day it was written and hadn't improved with age. Having three different man pages all with the same name didn't help. I find it easier to do the systemd way. systemctl list-timers --all It give you everything you need to track down what's going to happen and when. They are easy to set up as well. man systemd.timer -- After all is said and done, more is said than done.
John Andersen wrote:
On 09/15/2017 04:04 AM, Carlos E. R. wrote:
I understand how cron on SUSE works, since decades ago.
Not me.
I've had to read the man page or work from a template every time I wanted to do anything with Crontab. It was obtuse as hell the day it was written and hadn't improved with age. Having three different man pages all with the same name didn't help.
I find it easier to do the systemd way. systemctl list-timers --all
It give you everything you need to track down what's going to happen and when. They are easy to set up as well.
Umm, well - a matter of perspective perhaps. Creating a cron job - edit /etc/cron.d/mycronjob, add one line, save and exit. Hopefully you remember the syntax. Creating a systemd timer - - create the service unit - edit /etc/systemd/system/mycronjob.service, maybe 4-5 lines. Hopefully you remember the syntax. - create the timer - edit /etc/systemd/system/mycronjob.timer, maybe 4-5 lines. Hopefully you remember the syntax. then systemctl daemon-reload I actually don't mind that, I just wanted to compare. What I find less easy is to tell when cronjob is going to fire a) at 30 minutes past every 3rd hour. b) at 2,17,32,47 minutes past every hour c) 10 past midnight on the 1st of the month. d) Sunday at 04:00. -- Per Jessen, Zürich (13.6°C) http://www.cloudsuisse.com/ - your owncloud, hosted in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-09-15 19:42, Per Jessen wrote:
John Andersen wrote:
On 09/15/2017 04:04 AM, Carlos E. R. wrote:
I understand how cron on SUSE works, since decades ago.
Not me.
I've had to read the man page or work from a template every time I wanted to do anything with Crontab. It was obtuse as hell the day it was written and hadn't improved with age. Having three different man pages all with the same name didn't help.
I find it easier to do the systemd way. systemctl list-timers --all
It give you everything you need to track down what's going to happen and when. They are easy to set up as well.
Umm, well - a matter of perspective perhaps.
Creating a cron job - edit /etc/cron.d/mycronjob, add one line, save and exit. Hopefully you remember the syntax.
Creating a systemd timer -
- create the service unit - edit /etc/systemd/system/mycronjob.service, maybe 4-5 lines. Hopefully you remember the syntax. - create the timer - edit /etc/systemd/system/mycronjob.timer, maybe 4-5 lines. Hopefully you remember the syntax. then systemctl daemon-reload
I actually don't mind that, I just wanted to compare.
Hum.
What I find less easy is to tell when cronjob is going to fire
a) at 30 minutes past every 3rd hour. b) at 2,17,32,47 minutes past every hour c) 10 past midnight on the 1st of the month. d) Sunday at 04:00.
LOL. Those are not actually cronjobs :-P It is a script concoction SuSE made many years ago. More than two decades ago, I think. And it got much easier on recent versions to control. On a computer that runs 24*7, they will run same time as yesterday :-P -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
On Fri, 15 Sep 2017 20:56:03 +0200 "Carlos E. R." <robin.listas@telefonica.net> wrote:
On 2017-09-15 19:42, Per Jessen wrote:
What I find less easy is to tell when cronjob is going to fire
a) at 30 minutes past every 3rd hour. b) at 2,17,32,47 minutes past every hour c) 10 past midnight on the 1st of the month. d) Sunday at 04:00.
LOL. Those are not actually cronjobs :-P
Eh? First I copy the comment that should be in every crontab: # min hr DoM month DoW [uid] command #a 30 1,4,7,10,13,16,19,22 * * * #b 2,17,32,47 * * * * #c 10 0 1 * * #d 00 4 * * Sun What's not to like? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
* Dave Howorth <dave@howorth.org.uk> [09-15-17 16:35]:
On Fri, 15 Sep 2017 20:56:03 +0200 "Carlos E. R." <robin.listas@telefonica.net> wrote:
On 2017-09-15 19:42, Per Jessen wrote:
What I find less easy is to tell when cronjob is going to fire
a) at 30 minutes past every 3rd hour. b) at 2,17,32,47 minutes past every hour c) 10 past midnight on the 1st of the month. d) Sunday at 04:00.
LOL. Those are not actually cronjobs :-P
Eh?
First I copy the comment that should be in every crontab: # min hr DoM month DoW [uid] command
#a 30 1,4,7,10,13,16,19,22 * * *
#b 2,17,32,47 * * * *
#c 10 0 1 * *
#d 00 4 * * Sun
What's not to like?
or: # Note: Lines beginning with "#\" indicates a disabled task. # ######################################################################### #minute (0-59), # #| hour (0-23), # #| | day of the month (1-31), # #| | | month of the year (1-12), # #| | | | day of the week (0-6 with 0=Sunday). # #| | | | | commands # #0 2 * * 0,4 /etc/cron.d/logchecker # # */6 six times per unit (every 6 units) # ######################################################################### # -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-09-15 22:34, Dave Howorth wrote:
On Fri, 15 Sep 2017 20:56:03 +0200 "Carlos E. R." <> wrote:
On 2017-09-15 19:42, Per Jessen wrote:
What I find less easy is to tell when cronjob is going to fire
a) at 30 minutes past every 3rd hour. b) at 2,17,32,47 minutes past every hour c) 10 past midnight on the 1st of the month. d) Sunday at 04:00.
LOL. Those are not actually cronjobs :-P
Eh?
First I copy the comment that should be in every crontab: # min hr DoM month DoW [uid] command
#a 30 1,4,7,10,13,16,19,22 * * *
cer@Telcontar:~> cat /etc/cron.daily/logrotate #!/bin/sh # exit immediately if there is another instance running if checkproc /usr/sbin/logrotate; then /bin/logger -p cron.warning -t logrotate "ALERT another instance of logrotate is running - exiting" exit 1 fi ... It is not a crontab entry. It is a shell script. A bunch of them in that directory. :-) -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
* Carlos E. R. <robin.listas@telefonica.net> [09-15-17 18:04]:
On 2017-09-15 22:34, Dave Howorth wrote:
On Fri, 15 Sep 2017 20:56:03 +0200 "Carlos E. R." <> wrote:
On 2017-09-15 19:42, Per Jessen wrote:
What I find less easy is to tell when cronjob is going to fire
a) at 30 minutes past every 3rd hour. b) at 2,17,32,47 minutes past every hour c) 10 past midnight on the 1st of the month. d) Sunday at 04:00.
LOL. Those are not actually cronjobs :-P
Eh?
First I copy the comment that should be in every crontab: # min hr DoM month DoW [uid] command
#a 30 1,4,7,10,13,16,19,22 * * *
cer@Telcontar:~> cat /etc/cron.daily/logrotate #!/bin/sh
# exit immediately if there is another instance running if checkproc /usr/sbin/logrotate; then /bin/logger -p cron.warning -t logrotate "ALERT another instance of logrotate is running - exiting" exit 1 fi ...
It is not a crontab entry. It is a shell script. A bunch of them in that directory.
but they were initiated by cron, and now systemd logrotate.timer -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Dave Howorth wrote:
On Fri, 15 Sep 2017 20:56:03 +0200 "Carlos E. R." <robin.listas@telefonica.net> wrote:
On 2017-09-15 19:42, Per Jessen wrote:
What I find less easy is to tell when cronjob is going to fire
a) at 30 minutes past every 3rd hour. b) at 2,17,32,47 minutes past every hour c) 10 past midnight on the 1st of the month. d) Sunday at 04:00.
LOL. Those are not actually cronjobs :-P
Eh?
First I copy the comment that should be in every crontab: # min hr DoM month DoW [uid] command
#a 30 1,4,7,10,13,16,19,22 * * * #b 2,17,32,47 * * * * #c 10 0 1 * * #d 00 4 * * Sun
What's not to like?
Good example with "1,4,7,10,13,16,19,22", the actual job just uses "30 */3 * * *", but I also use the kind with an offset. -- Per Jessen, Zürich (10.1°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Carlos E. R. wrote:
On 2017-09-15 19:42, Per Jessen wrote:
What I find less easy is to tell when cronjob is going to fire
a) at 30 minutes past every 3rd hour. b) at 2,17,32,47 minutes past every hour c) 10 past midnight on the 1st of the month. d) Sunday at 04:00.
LOL. Those are not actually cronjobs :-P
They are scheduling entries, like I said: "... _when_ a cronjob is going to fire". I've got plenty of them on various machines.
It is a script concoction SuSE made many years ago. More than two decades ago, I think. And it got much easier on recent versions to control. On a computer that runs 24*7, they will run same time as yesterday :-P
Huh? -- Per Jessen, Zürich (10.0°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-09-16 08:15, Per Jessen wrote:
Carlos E. R. wrote:
On 2017-09-15 19:42, Per Jessen wrote:
What I find less easy is to tell when cronjob is going to fire
a) at 30 minutes past every 3rd hour. b) at 2,17,32,47 minutes past every hour c) 10 past midnight on the 1st of the month. d) Sunday at 04:00.
LOL. Those are not actually cronjobs :-P
They are scheduling entries, like I said: "... _when_ a cronjob is going to fire". I've got plenty of them on various machines.
It is a script concoction SuSE made many years ago. More than two decades ago, I think. And it got much easier on recent versions to control. On a computer that runs 24*7, they will run same time as yesterday :-P
Huh?
I suppose you are referring to the hourly/daily/weekly/monthly jobs. You just drop a script in the corresponding directory and it runs at those intervals. But those jobs are not themselves, strictly speaking, cronjobs. There is a single system cronjob that fires a SuSE script, which in turn starts all those scripts, one after the other. They don't have an exact time to run, but a range, configured in "/etc/sysconfig/cron". Now that I think: with systemd timers, it seems the idea is one timer per job. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
Carlos E. R. wrote:
On 2017-09-16 08:15, Per Jessen wrote:
Carlos E. R. wrote:
On 2017-09-15 19:42, Per Jessen wrote:
What I find less easy is to tell when cronjob is going to fire
a) at 30 minutes past every 3rd hour. b) at 2,17,32,47 minutes past every hour c) 10 past midnight on the 1st of the month. d) Sunday at 04:00.
LOL. Those are not actually cronjobs :-P
They are scheduling entries, like I said: "... _when_ a cronjob is going to fire". I've got plenty of them on various machines.
It is a script concoction SuSE made many years ago. More than two decades ago, I think. And it got much easier on recent versions to control. On a computer that runs 24*7, they will run same time as yesterday :-P
Huh?
I suppose you are referring to the hourly/daily/weekly/monthly jobs.
No, not at all. I was showing some more unusual scheduling examples, that are easily seen in one snap with "cat /etc/crontab /etc/cron.d/*" whereas it is not so easy with "systemctl list-timers". -- Per Jessen, Zürich (15.2°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-09-16 17:28, Per Jessen wrote:
Carlos E. R. wrote:
I suppose you are referring to the hourly/daily/weekly/monthly jobs.
No, not at all. I was showing some more unusual scheduling examples, that are easily seen in one snap with "cat /etc/crontab /etc/cron.d/*" whereas it is not so easy with "systemctl list-timers".
Ah, I see. It is worse for the logrotate timer, I have no idea when it runs. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith))
Carlos E. R. wrote:
On 2017-09-16 17:28, Per Jessen wrote:
Carlos E. R. wrote:
I suppose you are referring to the hourly/daily/weekly/monthly jobs.
No, not at all. I was showing some more unusual scheduling examples, that are easily seen in one snap with "cat /etc/crontab /etc/cron.d/*" whereas it is not so easy with "systemctl list-timers".
Ah, I see.
It is worse for the logrotate timer, I have no idea when it runs.
Oncalendar=daily Every day at midnight. At least "Daily" is quite clear (once you have looked it up). -- Per Jessen, Zürich (10.7°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Per Jessen wrote:
Carlos E. R. wrote:
On 2017-09-16 17:28, Per Jessen wrote:
Carlos E. R. wrote:
I suppose you are referring to the hourly/daily/weekly/monthly jobs.
No, not at all. I was showing some more unusual scheduling examples, that are easily seen in one snap with "cat /etc/crontab /etc/cron.d/*" whereas it is not so easy with "systemctl list-timers".
Ah, I see.
It is worse for the logrotate timer, I have no idea when it runs.
Oncalendar=daily
Every day at midnight. At least "Daily" is quite clear (once you have looked it up).
With an uncertainty span defined by "AccuracySec". It's a bit odd that logrotate has AccuracySec=12h. -- Per Jessen, Zürich (14.6°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-09-17 13:47, Per Jessen wrote:
Per Jessen wrote:
Carlos E. R. wrote:
On 2017-09-16 17:28, Per Jessen wrote:
Carlos E. R. wrote:
I suppose you are referring to the hourly/daily/weekly/monthly jobs.
No, not at all. I was showing some more unusual scheduling examples, that are easily seen in one snap with "cat /etc/crontab /etc/cron.d/*" whereas it is not so easy with "systemctl list-timers".
Ah, I see.
It is worse for the logrotate timer, I have no idea when it runs.
Oncalendar=daily
Every day at midnight. At least "Daily" is quite clear (once you have looked it up).
With an uncertainty span defined by "AccuracySec". It's a bit odd that logrotate has AccuracySec=12h.
I suppose that is to cover those machines that are not running at midnight. So, no choice of preferred time. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
On 09/15/2017 10:42 AM, Per Jessen wrote:
- create the service unit - edit /etc/systemd/system/mycronjob.service, maybe 4-5 lines. Hopefully you remember the syntax. - create the timer - edit /etc/systemd/system/mycronjob.timer, maybe 4-5 lines. Hopefully you remember the syntax. then systemctl daemon-reload
Edit one, save under new name. Don't we all do it that way? Syntax already in place. At my age, I've long ago become content to know where I can find an example, rather than remembering exact form. Lately, I'm content to remember where I can search for the name of something, so that I can then search for that thing. Soon I'll be content to remember the name of my search engine. Side note: systemd timers will allegedly wake a machine up from suspend so that it can run some task and then suspend it again. Haven't tested this yet. https://cmcenroe.me/2014/11/24/scheduled-suspend-and-resume-with-systemd.htm... -- After all is said and done, more is said than done. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
John Andersen wrote:
On 09/15/2017 10:42 AM, Per Jessen wrote:
- create the service unit - edit /etc/systemd/system/mycronjob.service, maybe 4-5 lines. Hopefully you remember the syntax. - create the timer - edit /etc/systemd/system/mycronjob.timer, maybe 4-5 lines. Hopefully you remember the syntax. then systemctl daemon-reload
Edit one, save under new name. Don't we all do it that way? Syntax already in place.
Very true. and with practice, I'll get the hang of the parameters too :-)
Side note: systemd timers will allegedly wake a machine up from suspend so that it can run some task and then suspend it again.
Sounds more like a BIOS feature, I'm sure I've seen or read of that.
Haven't tested this yet. https://cmcenroe.me/2014/11/24/scheduled-suspend-and-resume-with-systemd.htm...
Hmm, how does that work ? If the machine is suspended, how can anything run? -- Per Jessen, Zürich (9.0°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
16.09.2017 09:05, Per Jessen пишет:
John Andersen wrote:
On 09/15/2017 10:42 AM, Per Jessen wrote:
- create the service unit - edit /etc/systemd/system/mycronjob.service, maybe 4-5 lines. Hopefully you remember the syntax. - create the timer - edit /etc/systemd/system/mycronjob.timer, maybe 4-5 lines. Hopefully you remember the syntax. then systemctl daemon-reload
Edit one, save under new name. Don't we all do it that way? Syntax already in place.
Very true. and with practice, I'll get the hang of the parameters too :-)
Side note: systemd timers will allegedly wake a machine up from suspend so that it can run some task and then suspend it again.
Sounds more like a BIOS feature, I'm sure I've seen or read of that.
Haven't tested this yet. https://cmcenroe.me/2014/11/24/scheduled-suspend-and-resume-with-systemd.htm...
Hmm, how does that work ? If the machine is suspended, how can anything run?
systemd simply sets CLOCK_BOOTTIME_ALARM and kernel presumably tells BIOS to do it (although kernel is free do implement it differently) CLOCK_BOOTTIME_ALARM (since Linux 3.11) This clock is like CLOCK_BOOTTIME, but will wake the system if it is suspended. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-09-16 08:05, Per Jessen wrote:
John Andersen wrote:
Side note: systemd timers will allegedly wake a machine up from suspend so that it can run some task and then suspend it again.
Sounds more like a BIOS feature, I'm sure I've seen or read of that.
Haven't tested this yet. https://cmcenroe.me/2014/11/24/scheduled-suspend-and-resume-with-systemd.htm...
Hmm, how does that work ? If the machine is suspended, how can anything run?
The BIOS can program the CMOS clock chip (I think it is that one, it has its own battery) to wake up the board. You need support from the board and the power supply. Ie, the power supply has to be supplying some power to the board continuously, and I think it has a line that signals the PSU to go to full power on request from the board. It is an interesting feature, but has dangers. I think Windows 10 uses it: the machine can wake itself and run automatic updates. If it is a laptop on battery it of course depletes the battery (a bit or a lot). If the laptop is inside a bag it can heat up tremendously. Android uses it a lot. Often I find the battery totally depleted because some app wanted to do something and failed ("pocket" usually). -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
On 09/16/2017 07:06 AM, Carlos E. R. wrote:
It is an interesting feature, but has dangers. I think Windows 10 uses it: the machine can wake itself and run automatic updates. If it is a laptop on battery it of course depletes the battery (a bit or a lot). If the laptop is inside a bag it can heat up tremendously.
Because there are other brain dead operating systems, and someone may use it on a Laptop in a bag, is hardly a reason to call it dangerous. The cited article had a perfectly valid use case. I have a similar situation where a offsite backup machine takes daily morning backups of data from their local lan. I contemplated using this feature. But I've also looked at the alternative of a Raspberry Pi V3, and it will probably use less power. -- After all is said and done, more is said than done.
On 2017-09-16 19:21, John Andersen wrote:
On 09/16/2017 07:06 AM, Carlos E. R. wrote:
It is an interesting feature, but has dangers. I think Windows 10 uses it: the machine can wake itself and run automatic updates. If it is a laptop on battery it of course depletes the battery (a bit or a lot). If the laptop is inside a bag it can heat up tremendously.
Because there are other brain dead operating systems, and someone may use it on a Laptop in a bag, is hardly a reason to call it dangerous.
That someone was not the owner or the user of the laptop. It was the operating system designer.
The cited article had a perfectly valid use case. I have a similar situation where a offsite backup machine takes daily morning backups of data from their local lan. I contemplated using this feature. But I've also looked at the alternative of a Raspberry Pi V3, and it will probably use less power.
Of course there are use cases, I said it is a (very) interesting feature. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith))
On 2017-09-15 19:42, Per Jessen wrote:
John Andersen wrote:
On 09/15/2017 04:04 AM, Carlos E. R. wrote:
I understand how cron on SUSE works, since decades ago.
Not me.
I've had to read the man page or work from a template every time I wanted to do anything with Crontab. It was obtuse as hell the day it was written and hadn't improved with age. Having three different man pages all with the same name didn't help.
I find it easier to do the systemd way. systemctl list-timers --all
It give you everything you need to track down what's going to happen and when. They are easy to set up as well.
Umm, well - a matter of perspective perhaps.
Creating a cron job - edit /etc/cron.d/mycronjob, add one line, save and exit. Hopefully you remember the syntax.
Creating a systemd timer -
- create the service unit - edit /etc/systemd/system/mycronjob.service, maybe 4-5 lines. Hopefully you remember the syntax. - create the timer - edit /etc/systemd/system/mycronjob.timer, maybe 4-5 lines. Hopefully you remember the syntax. then systemctl daemon-reload
I actually don't mind that, I just wanted to compare.
What I find less easy is to tell when cronjob is going to fire
a) at 30 minutes past every 3rd hour. b) at 2,17,32,47 minutes past every hour c) 10 past midnight on the 1st of the month. d) Sunday at 04:00.
I just had a look on a 42.3 test system. Eleanor-423:~ # updatedb ; locate logrotate.timer /etc/systemd/system/timers.target.wants/logrotate.timer /usr/lib/systemd/system/logrotate.timer /var/lib/systemd/timers/stamp-logrotate.timer Eleanor-423:~ # Three possible files. Eleanor-423:~ # cat /usr/lib/systemd/system/logrotate.timer [Unit] Description=Daily rotation of log files Documentation=man:logrotate(8) man:logrotate.conf(5) [Timer] OnCalendar=daily AccuracySec=12h Persistent=true [Install] WantedBy=timers.target Eleanor-423:~ # There is no clue as to when exactly it will run, nor a time range... Another file is needed: Eleanor-423:~ # cat /usr/lib/systemd/system/logrotate.service [Unit] Description=Rotate log files Documentation=man:logrotate(8) man:logrotate.conf(5) ConditionACPower=true [Service] Type=oneshot ExecStart=/usr/sbin/logrotate /etc/logrotate.conf Nice=19 IOSchedulingClass=best-effort IOSchedulingPriority=7 Eleanor-423:~ # -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
Carlos E. R. wrote:
I just had a look on a 42.3 test system.
Eleanor-423:~ # updatedb ; locate logrotate.timer /etc/systemd/system/timers.target.wants/logrotate.timer /usr/lib/systemd/system/logrotate.timer /var/lib/systemd/timers/stamp-logrotate.timer Eleanor-423:~ #
Three possible files.
The direct way is "systemctl cat logrotate.timer". Then you'll see exactly which file(s) (base, overrides) were loaded etc. -- Per Jessen, Zürich (15.4°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-09-16 17:23, Per Jessen wrote:
Carlos E. R. wrote:
I just had a look on a 42.3 test system.
Eleanor-423:~ # updatedb ; locate logrotate.timer /etc/systemd/system/timers.target.wants/logrotate.timer /usr/lib/systemd/system/logrotate.timer /var/lib/systemd/timers/stamp-logrotate.timer Eleanor-423:~ #
Three possible files.
The direct way is "systemctl cat logrotate.timer". Then you'll see exactly which file(s) (base, overrides) were loaded etc.
I didn't know this command. I'll have to write a note to myself about it. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith))
Carlos E. R. wrote:
On 2017-09-14 14:37, Per Jessen wrote:
gumb wrote:
systemctl enable logrotate.timer Failed to execute operation: No such file or directory
systemctl status logrotate.service ● logrotate.service Loaded: not-found (Reason: No such file or directory) Active: inactive (dead)
I notice /var/log/journal/{string}/ has nearly 1GB of logs in it, going back as far as installation time.
Do you have logrotate installed? (it doesn't look like it).
Leap uses cron. /etc/cron.daily/logrotate
Ah, in Leap422 logrotate was not yet converted to systemd, okay. -- Per Jessen, Zürich (13.8°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-09-14 14:08, gumb wrote:
I notice /var/log/journal/{string}/ has nearly 1GB of logs in it, going back as far as installation time.
That one is handled differently, not by logrotate. /etc/systemd/journald.conf -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
participants (13)
-
Andrei Borzenkov -
Anton Aylward -
Carlos E. R. -
Dave Howorth -
Felix Miata -
Greg Freemyer -
gumb -
John Andersen -
Knurpht - Gertjan Lettink -
Patrick Shanahan -
Per Jessen -
Peter Suetterlin -
Wols Lists