On Wed, Sep 13, 2017 at 5:15 PM, Patrick Shanahan wrote:

logrotate is instigated by cron here.

More likely by logrotate.timer. -- 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 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

Felix Miata wrote:

Per Jessen composed on 2017-09-13 18:30 (UTC+0200):

...

https://bugzilla.opensuse.org/show_bug.cgi?id=1054353

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

* Patrick Shanahan [09-13-17 10:15]:

* Peter Suetterlin [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 13/09/17 22:14, Greg Freemyer wrote:

On Wed, Sep 13, 2017 at 9:48 AM, Peter Suetterlin 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

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

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)

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

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

On 2017-09-14 16:55, Patrick Shanahan wrote:

* Carlos E. R. [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)

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

Andrei Borzenkov wrote:

On Fri, Sep 15, 2017 at 9:10 AM, Per Jessen 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 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

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 ? 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

Op zaterdag 16 september 2017 17:35:44 CEST schreef Per Jessen: 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

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

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

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

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 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.

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)

* Dave Howorth [09-15-17 16:35]:

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 * * *

#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

* Carlos E. R. [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

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

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

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

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)

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

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 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))

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

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