[opensuse] Easter puzzle: sistemad logrotate.timer ?
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? slightly more complex: # 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] 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: # grep -i rotat /var/log/messages http://files.jessen.ch/saturn5-logrotate.txt -- Per Jessen, Zürich (5.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 Thu, Mar 24, 2016 at 11:33 AM, Per Jessen <per@computer.org> 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.
slightly more complex:
# 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]
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".
# grep -i rotat /var/log/messages http://files.jessen.ch/saturn5-logrotate.txt
-- Per Jessen, Zürich (5.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
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Andrei Borzenkov wrote:
On Thu, Mar 24, 2016 at 11:33 AM, Per Jessen <per@computer.org> 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?
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:
# grep -i rotat /var/log/messages http://files.jessen.ch/saturn5-logrotate.txt
grep 'Starting Daily rotation of log' saturn5-logrotate.txt 2016-03-11T10:03:11+01:00 guest54 systemd[1]: Starting Daily rotation of log files. 2016-03-11T23:22:16+01:00 saturn systemd[1]: Starting Daily rotation of log files. 2016-03-13T15:22:03+01:00 saturn systemd[1]: Starting Daily rotation of log files. 2016-03-18T14:59:04+01:00 saturn systemd[1]: Starting Daily rotation of log files. 2016-03-20T17:52:31+01:00 saturn systemd[1]: Starting Daily rotation of log files. 2016-03-20T20:26:03+01:00 saturn systemd[1]: Starting Daily rotation of log files. 2016-03-22T14:43:37+01:00 saturn systemd[1]: Starting Daily rotation of log files. 2016-03-22T15:13:37+01:00 saturn systemd[1]: Starting Daily rotation of log files. In the log I see: 2016-03-24T00:00:01+01:00 saturn systemd[1]: Starting Rotate log files... 2016-03-24T00:00:01+01:00 saturn systemd[1]: Started Rotate log files. but that is not the description from logrotate.timer: # /usr/lib/systemd/system/logrotate.timer [Unit] Description=Daily rotation of log files Documentation=man:logrotate(8) man:logrotate.conf(5) Those last two lines are from # /usr/lib/systemd/system/logrotate.service [Unit] Description=Rotate log files Documentation=man:logrotate(8) man:logrotate.conf(5) 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_. -- Per Jessen, Zürich (6.6°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
24.03.2016 12:35, Per Jessen пишет:
Andrei Borzenkov wrote:
On Thu, Mar 24, 2016 at 11:33 AM, Per Jessen <per@computer.org> 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday, 2016-03-24 at 19:56 +0300, Andrei Borzenkov wrote:
24.03.2016 12:35, Per Jessen пишет:
Andrei Borzenkov wrote:
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.
Well, it is systemd which is reinventing the wheel this time ;-) I rather prefer to receive an email when something extraordinary happens. Easy. Customizable. Traditional. - -- Cheers, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlb0RLAACgkQtTMYHG2NR9UbIgCfbcXR48qZHoPelypVx2/NEmEc 9acAn2Dyzpe9ZYjB8JtxY+wAgR9QYVyF =ADiB -----END PGP SIGNATURE-----
Andrei Borzenkov wrote:
24.03.2016 12:35, Per Jessen пишет:
Andrei Borzenkov wrote:
On Thu, Mar 24, 2016 at 11:33 AM, Per Jessen <per@computer.org> 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
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. More to the point, those triggered units can have separate actions for success & fail, pre and post. 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. -- 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
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
On 03/24/2016 05:18 PM, Per Jessen wrote:
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.
OK so I'm contortionist. I don't like noise. I don't want all that mail. In particular I don't want mail when things I know I've tested & debugged are wrong the way they should. I only want to know about them if they fail. Stuff I'm debugging I want to know that its supposed to have started, supposed to have finished, and if it did indeed do what I though I'd told it to. But once that's over, "silent running". This is LINUX not VMS. So I don't like you "broad brush" resulting from that single MAILTO style solution that always mail to me regardless. -- 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
-----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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday, 2016-03-24 at 12:08 +0300, Andrei Borzenkov wrote:
On Thu, Mar 24, 2016 at 11:33 AM, Per Jessen <per@computer.org> 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. - -- Cheers, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlbz5GYACgkQtTMYHG2NR9UdagCaA2GVTPbrkeLiYuH8VVD7jVTf T8AAn0zftZvmrPRBLFUPfhED6Xz5l4JO =1QbO -----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 <per@computer.org> 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" ...
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Content-ID: <alpine.LSU.2.20.1603242047020.14097@Grypbagne.inyvabe> 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 :-) Thanks! - -- Cheers, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlb0RDkACgkQtTMYHG2NR9WsIACeJrFBlkJxH+z0/KrIS5affM4k FpsAnikNo046uYjYsbQyDU/Z/HrwCbXs =PG/H -----END PGP SIGNATURE-----
Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Content-ID: <alpine.LSU.2.20.1603242047020.14097@Grypbagne.inyvabe>
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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. - -- Cheers, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlb0UsYACgkQtTMYHG2NR9VwbQCfRwmJTRSVcWWm6Ho0l5LPJW2t lgcAoIr4GH5b29PZJ4I37HgIej1Pkx6C =auZR -----END PGP SIGNATURE-----
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday, 2016-03-24 at 21:59 +0100, Yamaban wrote:
Hint on that: look at "ls -l /run/log/journal/*/" most often there are some bits for access missing, or just set wrong.
Ah! I see. The group is "systemd-journal", so I would just need to add my user to it. Doing that just now. [...] Yes, it seems to work, thanks :-) - -- Cheers, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlb0WaQACgkQtTMYHG2NR9Ua6ACeJpIT+Y3E8rBzJwXp9DFhJWXV uRkAn32N8KHOhPrzXJtZa1iOZFi8NEP2 =ae7v -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday, 2016-03-24 at 22:30 +0100, Per Jessen wrote:
Yamaban wrote:
On Thu, 24 Mar 2016 21:49, Carlos E. R. wrote:
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
Not in this 13.1: cer@Telcontar:~> ls -l /run/log/journal/*/ total 57600 - -rw-r----- 1 root systemd-journal 6553600 Mar 24 22:12 system.journal - -rw-r----- 1 root systemd-journal 6553600 Mar 22 19:07 system@1969ff58d2874fbcb986650483069ddb-00000000000445f7-00052ea1f4c62041.journal - -rw-r----- 1 root systemd-journal 6553600 Mar 23 11:49 system@1969ff58d2874fbcb986650483069ddb-00000000000458b4-00052ea715d384d9.journal ... - -- Cheers, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlb0YYQACgkQtTMYHG2NR9WjrQCfUf5/bLazXF+R3sxgFCEOIibA HesAn0W0TzCQLc02pjSGiyjcCAPBfPhP =q/ae -----END PGP SIGNATURE----- -- 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
Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
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.
In the man page? Obviously not, it's just a service unit.
Unless you mean that the "-u" option is documented, --since= is also documented, and from there deduce the whole line above,
I meant that the journalctl man-page describes the -u and the --since and -- until arguments.
and that it contains the entire output that the cron "mail" would have.
No, I don't see that described, I did realise that's what you were asking.
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.
I would certainly prefer that no system log data be available to an ordinary user. /Per -- 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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? - -- Cheers, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlb1DjQACgkQtTMYHG2NR9XI5QCcCzT2e3sYAOx2hUB4drpskQh+ FecAn2G681G6H7iIWYOVeXGODroI7S2v =QUT0 -----END PGP SIGNATURE-----
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
24.03.2016 23:34, Per Jessen пишет:
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?
systemd can be run as user instance and journalctl allows each user to see logs from own services. Access should be controlled on normal file access level. Looking on Leap access to current system journal (/var/log/journal/$UUID/system.journal) is restricted to root/system-journal, but archived journal files are world readable. Same for user journals. This sounds like a bug. For Leap: https://bugzilla.opensuse.org/show_bug.cgi?id=972612 Please submit bug report for 13.2 if you think it should be fixed. -- 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: <alpine.LSU.2.20.1603242047020.14097@Grypbagne.inyvabe>
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
ianseeks wrote:
On Thursday, 24 March 2016 21:34:58 GMT Per Jessen wrote:
Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Content-ID: <alpine.LSU.2.20.1603242047020.14097@Grypbagne.inyvabe>
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
On Leap421 and 13.2 both, running "journalctl" under a normal user gives me messages from mail, innd, cron etc., but only the archived record. Anyway, Andrei already opened a bugreport: https://bugzilla.opensuse.org/show_bug.cgi?id=972612 -- Per Jessen, Zürich (7.4°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 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 also FailureAction= After= some unit with argument ExecStartPre=, ExecStartPost= and of course Also= -- 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
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. -- Per Jessen, Zürich (10.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 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
Anton Aylward wrote:
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
You'll have to elaborate, what does systemd 229 add to the mix? -- Per Jessen, Zürich (10.4°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 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
Anton Aylward wrote:
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
That's what I don't understand, all of those are already present in 210. How do they help me with mailing output to MAILTO ? -- Per Jessen, Zürich (10.2°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 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
* Ruediger Meier <sweet_f_a@gmx.de> [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". -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://linuxcounter.net -- 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 <sweet_f_a@gmx.de> [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
On Thursday 24 March 2016, Ruediger Meier wrote:
On Thursday 24 March 2016, Patrick Shanahan wrote:
* Ruediger Meier <sweet_f_a@gmx.de> [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.
Sorry I was wrong here, at least if sendmail/postfix is used.
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, Per Jessen wrote:
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?
Ah of course, it should use sendmail per default. So at least server restart shouldn't be an issue. 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, 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
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? -- 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
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
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. hence my suggestion of klutzy use of the otehr items on a unit. Which package are you .timer units from? I can't find them in my #210 -- 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
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
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 -- 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
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
participants (9)
-
Andrei Borzenkov -
Anton Aylward -
Carlos E. R. -
Chris Murphy -
ianseeks -
Patrick Shanahan -
Per Jessen -
Ruediger Meier -
Yamaban