24.03.2016 12:35, Per Jessen пишет:

Andrei Borzenkov wrote:

...

On Thu, Mar 24, 2016 at 11:33 AM, Per Jessen wrote:

...

In one way there's a certain elegance to the systemd timer concept, and it certainly seems very flexible. OTOH I'm not sure I like having two timer mechanisms.

However, I have been looking at logrotate.timer, and have a couple of questions:

a) what is the systemd equivalent of cron's MAILTO setting?

There are none. Theoretically all program output is (supposed to be) captured by journal which makes it redundant.

Really, you're serious?

journal was not my idea, but you have you know your enemy. And yes, I think that storing everything in one place and then filtering as needed is at the end more productive than reinventing the wheel for every individual use case.

...

...

Clearly logrotate.timer is due to fire tonight at midnight, very good. What I don't understand is why it (apparently) didn't fire on Thu 2016-03-24 00:00:00 CET and on Wed 2016-03-23 00:00:00 CET, see below:

# systemctl status logrotate.timer logrotate.timer - Daily rotation of log files Loaded: loaded (/usr/lib/systemd/system/logrotate.timer; enabled) Active: active (waiting) since Tue 2016-03-22 15:13:37 CET; 1 day 18h ago Docs: man:logrotate(8) man:logrotate.conf(5)

Mar 22 15:13:37 saturn systemd[1]: Starting Daily rotation of log files. Mar 22 15:13:37 saturn systemd[1]: Started Daily rotation of log files.

Well, as it happens, it _did_ fire, but not according to the status above. What's funny is - on Tue 2016-03-22 15:13:37, it logged:

2016-03-22T15:13:37+01:00 saturn systemd[1]: Starting Daily rotation of log files. 2016-03-22T15:13:37+01:00 saturn systemd[1]: Started Daily rotation of log files.

The last two days at midnight, those two messages do not appear:

They do according to the very log you posted. Assuming you are speaking about "saturn".

Yes, currently the host is "saturn" internally, "saturn5" externally. "saturn5" is meant to replace the ageing "saturn".

You must have better glasses than me:

You misunderstand. The actual log rotation (logrotate.service) has description "Rotate log files" and happens every day at 00:00 give or take couple of seconds. What you see is (re-)starting of *timer* unit itself. Why exactly it happens needs some more investigation, but is not related to actual log rotation. ...

Ah, I think I get it know - the message "Starting Daily rotation of log files" indicates the start of the _timer_ (on boot-up). The later message "Starting Rotate log file" is the timer kicking in and starting the _logrotate_.

Oops. I had read full befyore answering :)

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Andrei Borzenkov wrote:

24.03.2016 12:35, Per Jessen пишет:

...

Andrei Borzenkov wrote:

...

On Thu, Mar 24, 2016 at 11:33 AM, Per Jessen wrote:

...

In one way there's a certain elegance to the systemd timer concept, and it certainly seems very flexible. OTOH I'm not sure I like having two timer mechanisms.

However, I have been looking at logrotate.timer, and have a couple of questions:

a) what is the systemd equivalent of cron's MAILTO setting?

There are none. Theoretically all program output is (supposed to be) captured by journal which makes it redundant.

Really, you're serious?

journal was not my idea, but you have you know your enemy.

Completely agree, I was just really surprised that systemd timer units do not support a MAILTO. With that handicap, I don't see them replacing cron- jobs any time soon. In fact, I think maintainers need to be careful when/if they consider it. /Per -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Anton Aylward wrote:

On 03/24/2016 04:21 PM, Per Jessen wrote:

...

Completely agree, I was just really surprised that systemd timer units do not support a MAILTO. With that handicap, I don't see them replacing cron- jobs any time soon. In fact, I think maintainers need to be careful when/if they consider it.

I would not expect the *.timer units to incorporate the notification when the units they trigger can.

I would. The timer is the important bit, not what is being executed. I can run the same service unit from different timers. Just like I can have a crontab: MAILTO=anton * 1,3,5,7 * * * anton echo blahblah MAILTO=per * 2,4,6,8 * * * per echo blahblah MAILTO=carlos * 9,11,13,15 * * * carlos echo blahblah MAILTO=andrei * 10,12,14,16 * * * andrei echo blahblah

More to the point, those triggered units can have separate actions for success & fail, pre and post.

Anton, can you think of how to emulate MAILTO for e.g. the logrotate job? With cron, any output from the specific job is emailed to $MAILTO, regardless of whether it fails or not.

OnFailure= A space-separated list of one or more units that are activated when this unit enters the "failed" state.

Shame that isn't command rather than unit. Doing parametrized units is a ... bother!

However there is

ExecStartPre=, ExecStartPost= Additional commands that are executed before or after the command in ExecStart=, respectively. Syntax is the same as for ExecStart=, except that multiple command lines are allowed and the commands are executed one after the other, serially.

So the "ExecStart" is the logrotate command and after that completes you have a "ExecStartPost" that does the emailing.

Yes you need "mail -s subject ...." type. Can that include a body? Well never mind, just "echo" the body in or use a 'here' document form.

Seems like an awful lot of hassle compared to a single line of MAILTO=. I'm all for systemd, I even find it elegant, but what you're suggesting is for contortionists. /Per -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday, 2016-03-24 at 22:18 +0100, Per Jessen wrote:

Anton, can you think of how to emulate MAILTO for e.g. the logrotate job? With cron, any output from the specific job is emailed to $MAILTO, regardless of whether it fails or not.

The system cron jobs you can configure to mail on error, and ignore if not, I think. One advantage, IMO, of these mails is that you get the exact text that the command would display on the terminal, not a formatted log with timestamps.

...

Yes you need "mail -s subject ...." type. Can that include a body? Well never mind, just "echo" the body in or use a 'here' document form.

Seems like an awful lot of hassle compared to a single line of MAILTO=. I'm all for systemd, I even find it elegant, but what you're suggesting is for contortionists.

Yep :-)) - -- Cheers, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlb0YNwACgkQtTMYHG2NR9UAnQCfd2fzHiUhvDW+TX9n08feO+P+ IZYAniQg4xOFHCzHDnXhg8MEnA15i20z =O/PT -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

24.03.2016 15:58, Carlos E. R. пишет:

On Thursday, 2016-03-24 at 12:08 +0300, Andrei Borzenkov wrote:

...

On Thu, Mar 24, 2016 at 11:33 AM, Per Jessen wrote:

...

...

a) what is the systemd equivalent of cron's MAILTO setting?

...

There are none. Theoretically all program output is (supposed to be) captured by journal which makes it redundant.

What would be the procedure to obtain that ouput? That is, the "journalctl" options needed to obtain that output.

journalctl -u logrotate.service --since="..." --until="..." ... It is even described in "man journalctl" ...

Carlos E. R. wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Content-ID:

On Thursday, 2016-03-24 at 19:58 +0300, Andrei Borzenkov wrote:

...

24.03.2016 15:58, Carlos E. R. пишет:

...

...

What would be the procedure to obtain that ouput? That is, the "journalctl" options needed to obtain that output.

journalctl -u logrotate.service --since="..." --until="..." ...

It is even described in "man journalctl" ...

Not in mine :-)

I guess your systemd is pre-195? The man page in 12.3 has the description. Another completely separate question - it seems to me that journalctl gives any ordinary user access to (what would otherwise be) log data? That's not good. I guess journalctl ought to be only accessible by root? /Per -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Thu, 24 Mar 2016 21:49, Carlos E. R. wrote:

On Thursday, 2016-03-24 at 21:34 +0100, Per Jessen wrote:

...

Carlos E. R. wrote:

...

On Thursday, 2016-03-24 at 19:58 +0300, Andrei Borzenkov wrote:

...

24.03.2016 15:58, Carlos E. R. пишет:

...

...

What would be the procedure to obtain that ouput? That is, the "journalctl" options needed to obtain that output.

journalctl -u logrotate.service --since="..." --until="..." ...

It is even described in "man journalctl" ...

Not in mine :-)

I guess your systemd is pre-195? The man page in 12.3 has the description.

I have 13.1 (210), and search for "logrotate" finds nothing. Unless you mean that the "-u" option is documented, --since= is also documented, and from there deduce the whole line above, and that it contains the entire output that the cron "mail" would have.

The examples section in the manual is exceedingly short.

Even then I find difficult how to produce the output of a particular logrotate session. First you have to find out when it did run. Fortunately, 13.1 doesn't use this new method.

...

Another completely separate question - it seems to me that journalctl gives any ordinary user access to (what would otherwise be) log data? That's not good. I guess journalctl ought to be only accessible by root?

Not complete access. Some entries you can read, some you can't. I haven't figured out which entries I get or how to change the behaviour, because I typically add my admin user to the root group in order to be able to read the logs as that user.

Hint on that: look at "ls -l /run/log/journal/*/" most often there are some bits for access missing, or just set wrong. - Yamaban

Yamaban wrote:

On Thu, 24 Mar 2016 21:49, Carlos E. R. wrote:

...

On Thursday, 2016-03-24 at 21:34 +0100, Per Jessen wrote:

...

Another completely separate question - it seems to me that journalctl gives any ordinary user access to (what would otherwise be) log data? That's not good. I guess journalctl ought to be only accessible by root?

Not complete access. Some entries you can read, some you can't. I haven't figured out which entries I get or how to change the behaviour, because I typically add my admin user to the root group in order to be able to read the logs as that user.

Hint on that: look at "ls -l /run/log/journal/*/" most often there are some bits for access missing, or just set wrong.

Yup, it's world-readable. Same in Leap421. # ls -l /run/log/journal/*/ total 8192 -rwxr-xr-x 1 root systemd-journal 8388608 Mar 24 22:27 system.journal /Per -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On my system it's: drwxr-sr-x+ 1 root systemd-journal 1478 Mar 22 15:14 358f3fdc5df34832b44a6816f3b04881 # getfacl * # file: 358f3fdc5df34832b44a6816f3b04881 # owner: root # group: systemd-journal # flags: -s- user::rwx group::r-x group:adm:r-x group:wheel:r-x mask::r-x other::r-x default:user::rwx default:group::r-x default:group:adm:r-x default:group:wheel:r-x default:mask::r-x default:other::r-x But inside it's 640 for system journals and 650 for user journals. So not world readable. World listable however Chris Murphy -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Thursday, 24 March 2016 21:49:10 GMT Carlos E. R. wrote:

On Thursday, 2016-03-24 at 21:34 +0100, Per Jessen wrote:

...

Carlos E. R. wrote:

...

On Thursday, 2016-03-24 at 19:58 +0300, Andrei Borzenkov wrote:

...

24.03.2016 15:58, Carlos E. R. пишет:

...

What would be the procedure to obtain that ouput? That is, the "journalctl" options needed to obtain that output.

journalctl -u logrotate.service --since="..." --until="..." ...

It is even described in "man journalctl" ...

Not in mine :-)

I guess your systemd is pre-195? The man page in 12.3 has the description.

I have 13.1 (210), and search for "logrotate" finds nothing. Unless you mean that the "-u" option is documented, --since= is also documented, and from there deduce the whole line above, and that it contains the entire output that the cron "mail" would have.

Are you running it as "su" or the user?

The examples section in the manual is exceedingly short.

Even then I find difficult how to produce the output of a particular logrotate session. First you have to find out when it did run. Fortunately, 13.1 doesn't use this new method.

...

Another completely separate question - it seems to me that journalctl gives any ordinary user access to (what would otherwise be) log data? That's not good. I guess journalctl ought to be only accessible by root?

Not complete access. Some entries you can read, some you can't. I haven't figured out which entries I get or how to change the behaviour, because I typically add my admin user to the root group in order to be able to read the logs as that user.

-- Cheers, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Friday, 25 March 2016 11:08:52 GMT Carlos E. R. wrote:

On Friday, 2016-03-25 at 09:06 -0000, ianseeks wrote:

...

On Thursday, 24 March 2016 21:49:10 GMT Carlos E. R. wrote:

...

On Thursday, 2016-03-24 at 21:34 +0100, Per Jessen wrote:

...

Carlos E. R. wrote:

...

On Thursday, 2016-03-24 at 19:58 +0300, Andrei Borzenkov wrote:

...

24.03.2016 15:58, Carlos E. R. пишет: > What would be the procedure to obtain that ouput? That is, the > "journalctl" options needed to obtain that output.

journalctl -u logrotate.service --since="..." --until="..." ...

It is even described in "man journalctl" ...

Not in mine :-)

I guess your systemd is pre-195? The man page in 12.3 has the description.

I have 13.1 (210), and search for "logrotate" finds nothing. Unless you mean that the "-u" option is documented, --since= is also documented, and from there deduce the whole line above, and that it contains the entire output that the cron "mail" would have.

Are you running it as "su" or the user?

Are you serious? For "man journalctl"? Or are you thinking of something else?

No, for the output from journalctl - looks like i mixed up the questions. Somewhere in the thread someone was missing the output and when i read this " I have 13.1 (210), and search for "logrotate" finds nothing." i thought it meant the output was the "missing" bit. I've got systemd 228 and the "-u" is documented and i'm on 13.1 tumbleweed

-- Cheers, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Thursday, 24 March 2016 21:34:58 GMT Per Jessen wrote:

Carlos E. R. wrote:

...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Content-ID:

On Thursday, 2016-03-24 at 19:58 +0300, Andrei Borzenkov wrote:

...

24.03.2016 15:58, Carlos E. R. пишет:

...

What would be the procedure to obtain that ouput? That is, the "journalctl" options needed to obtain that output.

journalctl -u logrotate.service --since="..." --until="..." ...

It is even described in "man journalctl" ...

Not in mine :-)

I guess your systemd is pre-195? The man page in 12.3 has the description.

Another completely separate question - it seems to me that journalctl gives any ordinary user access to (what would otherwise be) log data? That's not good. I guess journalctl ought to be only accessible by root?

On my system, running journalctl seems to only give data for that user hence no logrotate data, but if i run it under "su" i get logrotate records

/Per

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 03/24/2016 09:30 AM, Per Jessen wrote:

Anton Aylward wrote:

...

On 03/24/2016 04:33 AM, Per Jessen wrote:

...

a) what is the systemd equivalent of cron's MAILTO setting?

It occurs to me that the .timer fires up some other unit and in that unit you can have any or all of

Onfailure= ... mail to user = name, subject = failure body = whatever

This would be a list of units to be activated?

I presume so, but I thin there's some way of using the "@" syntax to parametrise it.

Nah, if I have to jump through that many hoops, I think I'll revert to cron+MAILTO.

Or somehow get hold of #229 -- 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

On 03/24/2016 10:19 AM, Per Jessen wrote:

Anton Aylward wrote:

...

Or somehow get hold of #229

You'll have to elaborate, what does systemd 229 add to the mix?

From https://www.freedesktop.org/software/systemd/man/systemd-tmpfiles.html Synopsis systemd-tmpfiles [OPTIONS...] [CONFIGFILE...] systemd-tmpfiles-setup.service systemd-tmpfiles-setup-dev.service systemd-tmpfiles-clean.service systemd-tmpfiles-clean.timer -- 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

On Thursday 24 March 2016, Per Jessen wrote:

Anton Aylward wrote:

...

On 03/24/2016 04:33 AM, Per Jessen wrote:

...

a) what is the systemd equivalent of cron's MAILTO setting?

It occurs to me that the .timer fires up some other unit and in that unit you can have any or all of

Onfailure= ... mail to user = name, subject = failure body = whatever

This would be a list of units to be activated?

...

also

FailureAction=

That one doesn't seem to be in my man page, maybe its new.

...

After= some unit with argument

ExecStartPre=, ExecStartPost=

and of course

Also=

Nah, if I have to jump through that many hoops, I think I'll revert to cron+MAILTO.

But this is not the modern way ;) BTW note that crond's email support is also not perfect. At least the one openSUSE is installing per default does some things wrong which other crond's do better: openSUSE's cronie connects to the sendmail socket already when the jobs starts and writes your job output directly to that socket. This means you may not get that mail if the mail server restarts while the job is running. Also many jobs at the same time will cause "too many open files" errors. Last but not least the email does not contain any information when the job was finished, only start time. My knowledge is a few years old but I don't think these issues have changed/fixed allthough they have been reported. cu, Rudi -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Thursday 24 March 2016, Patrick Shanahan wrote:

* Ruediger Meier [03-24-16 09:58]: [...]

...

openSUSE's cronie connects to the sendmail socket already when the jobs starts and writes your job output directly to that socket. This means you may not get that mail if the mail server restarts while the job is running. Also many jobs at the same time will cause "too many open files" errors. Last but not least the email does not contain any information when the job was finished, only start time.

date-stamp in the email headers will indicate a relatively close approximation of the "job finished time".

Not for (default) local delivery via /var/mail/$user. The first local mailserver writes the date when the socket was opened to the header. Non-local delivery would add more headers with dates later but you can't be sure that their clock goes right (unless you don't own them too). See for example my mail in the other thread "[opensuse] test systemd" However it's cronie's fault. One should click the "send button" when the email is finished. cu, Rudi -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Ruediger Meier wrote:

On Thursday 24 March 2016, Per Jessen wrote:

...

Nah, if I have to jump through that many hoops, I think I'll revert to cron+MAILTO.

But this is not the modern way ;)

Hehe - I don't mind the modern way, as long as it does what the old-fashioned way does :-) Preferably easier, faster and better too!.

BTW note that crond's email support is also not perfect. At least the one openSUSE is installing per default does some things wrong which other crond's do better:

openSUSE's cronie connects to the sendmail socket already when the jobs starts and writes your job output directly to that socket. This means you may not get that mail if the mail server restarts while the job is running. Also many jobs at the same time will cause "too many open files" errors. Last but not least the email does not contain any information when the job was finished, only start time.

I was not aware. I thought cronie used sendmail, it surely can't rely on localhost:25 being open? -- Per Jessen, Zürich (10.5°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 Thursday 24 March 2016, Anton Aylward wrote:

On Thursday 24 March 2016, Per Jessen wrote:

...

In one way there's a certain elegance to the systemd timer concept, and it certainly seems very flexible. OTOH I'm not sure I like having two timer mechanisms.

How does it work with timers created by the users? Do their jobs only run if the user is logged in? Does it need one systemd --user instance for each user, even they all have only one yearly job?

...

a) what is the systemd equivalent of cron's MAILTO setting?

It occurs to me that the .timer fires up some other unit and in that unit you can have any or all of

Onfailure= ... mail to user = name, subject = failure body = whatever

also

FailureAction=

After= some unit with argument

ExecStartPre=, ExecStartPost=

and of course

Also=

Has each user to repeat this step for all of his jobs just to get an email to $USER@$HOST? cu, Rudi -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Anton Aylward wrote:

On 03/24/2016 04:33 AM, Per Jessen wrote:

...

# systemctl list-timers --all NEXT LEFT UNIT ACTIVATES Thu 2016-03-24 15:27:46 CET 6h left systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service Fri 2016-03-25 00:00:00 CET 14h left logrotate.timer logrotate.service [snip]

Hmm, what sysem is this on, what version of systemd?

systemd-210. It's openSUSE 13.2 -- Per Jessen, Zürich (10.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

Anton Aylward wrote:

On 03/24/2016 09:22 AM, Per Jessen wrote:

...

Anton Aylward wrote:

...

On 03/24/2016 04:33 AM, Per Jessen wrote:

...

# systemctl list-timers --all NEXT LEFT UNIT ACTIVATES Thu 2016-03-24 15:27:46 CET 6h left systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service Fri 2016-03-25 00:00:00 CET 14h left logrotate.timer logrotate.service [snip]

Hmm, what sysem is this on, what version of systemd?

systemd-210. It's openSUSE 13.2

Same here. It looks to me as if for #210 logrotate is a mix of the old and the new; scheduled by systemd.timer rather than cron, but not actually a systemd function.

No, I think logrotate is systemd. Yes - # systemctl status logrotate logrotate.service - Rotate log files Loaded: loaded (/usr/lib/systemd/system/logrotate.service; static) Active: inactive (dead)

Which package are you .timer units from? I can't find them in my #210

logrotate-3.8.7 It's been there for a while, I just haven't been migrating any production systems to 13.2. -- Per Jessen, Zürich (10.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

Anton Aylward wrote:

On 03/24/2016 04:33 AM, Per Jessen wrote:

...

In one way there's a certain elegance to the systemd timer concept, and it certainly seems very flexible. OTOH I'm not sure I like having two timer mechanisms.

However, I have been looking at logrotate.timer, and have a couple of questions:

a) what is the systemd equivalent of cron's MAILTO setting?

Have you seen https://www.freedesktop.org/software/systemd/man/systemd-tmpfiles.html That's for #229 I'm stuck on #210 and don't see a path to #229 for 13.1 or 13.2

The timer is installed with 210 though. -- Per Jessen, Zürich (10.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