Yamaban wrote:

On Sun, 7 May 2023 11:55, Per Jessen wrote:

...

I was just working on a new logrotate setup (and expecting to get some error output) when I realised systemd timers don't have any MAILTO option, like cron does.

Having googled it a bit, I see some concoctions involving OnFailure scripts, but is that currently the best/only solution?

Thorsten Kukuk initated this sub-package in Nov.2022: https://manpages.opensuse.org/systemd-status-mail

That may be an answer (haven't tested it myself)

Thanks, that looks useful. I guess I was thinking of an option for the timer unit, as a general thing, but I think this will do the job too. -- Per Jessen, Zürich (22.4°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes

On 07/05/2023 13:38, Per Jessen wrote:

Per Jessen wrote:

...

Yamaban wrote:

...

On Sun, 7 May 2023 11:55, Per Jessen wrote:

...

I was just working on a new logrotate setup (and expecting to get some error output) when I realised systemd timers don't have any MAILTO option, like cron does.

Having googled it a bit, I see some concoctions involving OnFailure scripts, but is that currently the best/only solution? Thorsten Kukuk initated this sub-package in Nov.2022: https://manpages.opensuse.org/systemd-status-mail

That may be an answer (haven't tested it myself) Thanks, that looks useful. I guess I was thinking of an option for the timer unit, as a general thing, but I think this will do the job too. Hmm, slight twist - I want the output whenever there is any, i.e. same behaviour as with cron. I guess I have to use OnSuccess= and OnFailure= both. I'll check it out.

For me, OnSuccess and OnFailure didn't do what I needed ( an email notification regardless of success or failure but showing which). I did this for notification of my nightly rmt job: In the systemd rmt-server-mirror.service file, add an ExecStopPost:

ExecStopPost=/bin/bash "/usr/local/sbin/svcstop.sh"

Then create this script at /usr/local/sbin/svcstop.sh:

rmt:/etc/systemd/system # cat /usr/local/sbin/svcstop.sh #!/bin/bash # # Script to email on service stop # intended to be run by a systemd service

JRNL="$(/usr/bin/journalctl -u rmt-server-mirror.service -g 'WARN' --since yesterday)" EMAIL="<my email address>" S1="Email from rmt, successful" S2="Email from rmt, failure"

if [[ $EXIT_STATUS == 0 ]]; then         SUBJECT="$S1" else         SUBJECT="$S2" fi

# the mailx option sendwait prevents it from forking, enabling systemd to manage it /usr/bin/mailx -Ssendwait -s "$SUBJECT" "$EMAIL" <<< "$JRNL"

exit 0

Per Jessen wrote:

Until I realised I would need to install the systemd-status-mail service in my user config too :-(

Okay, that was easily done - just copied the service unit over to the user side. /usr/lib/systemd/user/. Probably ought to be packaged like that. I had to remove User= and Group= from the service unit though. Next the systemd-status-mail script would also need to be sensitive to whether it is being invoked in user mode or system mode :-( Maybe ExecStopPost is the better option. Side question - how do I make a user timer run when the user is not logged in? -- Per Jessen, Zürich (15.2°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes

Andrei Borzenkov wrote:

On 07.05.2023 18:58, Per Jessen wrote:

...

Side question - how do I make a user timer run when the user is not logged in?

If you enable lingering for a user, systemd user instance is started on boot (instead of first time user logs in). You will need configure your unit to be auto-started.

Note that it will start everything. There is no way to start one single unit. I am not sure if it is possible to distinguish between start due to lingering or start due to use logon. It depends on what is started by various desktop environments.

I think that is all okay - I am only looking to emulate the crontab behaviour as closely as possible. For the user, there are two key things - running a job regularly (most often daily) and on reboot. (the @reboot crontab entry).

loginctl enable-linger

ah, thanks! that was going to be my next question :-) -- Per Jessen, Zürich (17.0°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes

Carlos E. R. wrote:

On 2023-05-07 18:26, Per Jessen wrote:

...

Andrei Borzenkov wrote:

...

On 07.05.2023 18:58, Per Jessen wrote:

...

Side question - how do I make a user timer run when the user is not logged in?

If you enable lingering for a user, systemd user instance is started on boot (instead of first time user logs in). You will need configure your unit to be auto-started.

Note that it will start everything. There is no way to start one single unit. I am not sure if it is possible to distinguish between start due to lingering or start due to use logon. It depends on what is started by various desktop environments.

I think that is all okay - I am only looking to emulate the crontab behaviour as closely as possible. For the user, there are two key things - running a job regularly (most often daily) and on reboot. (the @reboot crontab entry).

Huh... what's wrong with using crontab instead? Less work.

One key thing is that crontab keeps its user tabs in the /var filesystem. That is annoying and means extra work when doing backups. Second, same reason why we are moving toward systemd timers on the system side. -- Per Jessen, Zürich (15.2°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes

Carlos E. R. wrote:

On 2023-05-07 20:37, Per Jessen wrote:

...

Carlos E. R. wrote:

...

On 2023-05-07 18:26, Per Jessen wrote:

...

Andrei Borzenkov wrote:

...

On 07.05.2023 18:58, Per Jessen wrote:

...

Side question - how do I make a user timer run when the user is not logged in?

If you enable lingering for a user, systemd user instance is started on boot (instead of first time user logs in). You will need configure your unit to be auto-started.

Note that it will start everything. There is no way to start one single unit. I am not sure if it is possible to distinguish between start due to lingering or start due to use logon. It depends on what is started by various desktop environments.

I think that is all okay - I am only looking to emulate the crontab behaviour as closely as possible. For the user, there are two key things - running a job regularly (most often daily) and on reboot. (the @reboot crontab entry).

Huh... what's wrong with using crontab instead? Less work.

One key thing is that crontab keeps its user tabs in the /var filesystem.

Ok.

Didn't think of that, because when I do a backup I take it all. Mail is also in var. Databases.

This is a per-user/-customer backup, for privacy regulations but also (by coincidence) helps migrating that user/customer to a different host. No mail and no databases involved, databases are handled separately. -- Per Jessen, Zürich (13.8°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes

On Sun, 07 May 2023 15:55:33 +0200 Per Jessen wrote:

G McAlister wrote:

...

On 07/05/2023 13:38, Per Jessen wrote:

...

Per Jessen wrote:

Hmm, slight twist - I want the output whenever there is any, i.e. same behaviour as with cron. I guess I have to use OnSuccess= and OnFailure= both. I'll check it out.

Just to finish off that bit - systemd-status-mail does not seem to have a way of specifying the MAILTO recipient, per timer? (I may have overlooked it). I also spent quite a bit of time wrestling with

Failed to enqueue OnFailure= job, ignoring: Unit systemd-status-mail@myfirst.service.service not found.

Until I realised I would need to install the systemd-status-mail service in my user config too :-(

...

For me, OnSuccess and OnFailure didn't do what I needed ( an email notification regardless of success or failure but showing which).

Right, that's pretty much what I am after - we use quite a few cron jobs for things like regular reports, log extracts, all kinds of stuff. Usually daily jobs, with output just sent to MAILTO.

The arch wiki page mentioned some utility that would parse a cron file and implement systemd-timers, including mail. Perhaps that's worth a look? (I haven't myself, sorry)

...

I did this for notification of my nightly rmt job: In the systemd rmt-server-mirror.service file, add an ExecStopPost: ExecStopPost=/bin/bash "/usr/local/sbin/svcstop.sh"

Ah, I hadn't thought of that option.

...

...

/usr/bin/mailx -Ssendwait -s "$SUBJECT" "$EMAIL" <<< "$JRNL"

Right, that's the sort of thing I imagined too, I would just prefer to leave the EMAIL definition in the timer job (somehow). Maybe with an instance variable.

Per Jessen wrote:

Dave Howorth wrote:

...

...

Right, that's pretty much what I am after - we use quite a few cron jobs for things like regular reports, log extracts, all kinds of stuff. Usually daily jobs, with output just sent to MAILTO.

The arch wiki page mentioned some utility that would parse a cron file and implement systemd-timers, including mail. Perhaps that's worth a look? (I haven't myself, sorry)

Dave, do you have a URL for that? I have the arch wiki page: https://wiki.archlinux.org/title/systemd/Timers There is a reference to systemd-cron https://aur.archlinux.org/packages/systemd-cron ( and somewhere I even found this: :-) https://github.com/dtan4/ct2stimer (no mention of MAILTO though). I have also just now seen that there is a "systemd-crontab-generator", that sounds like something to take a closer look at. -- Per Jessen, Zürich (18.4°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes

Dave Howorth wrote:

On Mon, 08 May 2023 10:58:03 +0200 Per Jessen wrote:

...

Dave, do you have a URL for that?

I have the arch wiki page: https://wiki.archlinux.org/title/systemd/Timers

Yes, section 6.4 of that page says "Several of the caveats can be worked around by installing a package that parses a traditional crontab to configure the timers, like systemd-cron. It can provide the missing MAILTO feature."

Thanks, I must go see my optometrist, urgently.

...

There is a reference to systemd-cron https://aur.archlinux.org/packages/systemd-cron (

which you already found?

I have not yet taken a closer look - I'm pondering why there would be a need for both cron and timers. Maybe this systemd-cron thing is quite new, I see no package for TW nor for Leap. However(!), on tw I do see a "systemd-generator-cron2timer ...

...

I have also just now seen that there is a "systemd-crontab-generator", that sounds like something to take a closer look at.

That's what systemd.cron runs apparently. However, note that https://manpages.ubuntu.com/manpages/focal/man7/systemd.cron.7.html says : "LIMITATIONS This cron replacement only send mails on failure. The log of jobs is saved in systemd journal."

So perhaps it is of no use to you.

Yeah, it sounds like it is using the OnFailure facility. TBH, I'm beginning to have my doubts - last night I was just testing a new logrotate setup, and I clearly had not quite understood how the "preremove" feature works. From my regular cronjob, I would have had the warning, from the systemd timer I got nothing. -- Per Jessen, Zürich (21.1°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes

Per Jessen wrote:

Per Jessen wrote:

...

systemd-generator-cron2timer .

Hmm, that didn't go well:

Sorry, that is the poorest conversion script I have ever seen. Ignore it, it must be unfinished. -- Per Jessen, Zürich (19.7°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes

Andrei Borzenkov wrote:

On 08.05.2023 14:59, Per Jessen wrote:

...

Per Jessen wrote:

...

Per Jessen wrote:

...

systemd-generator-cron2timer .

Hmm, that didn't go well:

Sorry, that is the poorest conversion script I have ever seen. Ignore it, it must be unfinished.

It does exactly what it claims to do.

Systemd generator to create timer units from scripts in /etc/cron.{hourly,daily,weekly,monthly,yearly}

Except it ignores MAILTO :-) -- Per Jessen, Zürich (17.5°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes

On 07.05.2023 16:07, G McAlister wrote:

On 07/05/2023 13:38, Per Jessen wrote:

...

Per Jessen wrote:

...

Yamaban wrote:

...

On Sun, 7 May 2023 11:55, Per Jessen wrote:

...

I was just working on a new logrotate setup (and expecting to get some error output) when I realised systemd timers don't have any MAILTO option, like cron does.

Having googled it a bit, I see some concoctions involving OnFailure scripts, but is that currently the best/only solution? Thorsten Kukuk initated this sub-package in Nov.2022: https://manpages.opensuse.org/systemd-status-mail

That may be an answer (haven't tested it myself) Thanks, that looks useful. I guess I was thinking of an option for the timer unit, as a general thing, but I think this will do the job too. Hmm, slight twist - I want the output whenever there is any, i.e. same behaviour as with cron. I guess I have to use OnSuccess= and OnFailure= both. I'll check it out.

For me, OnSuccess and OnFailure didn't do what I needed ( an email notification regardless of success or failure but showing which).

I did this for notification of my nightly rmt job:

In the systemd rmt-server-mirror.service file, add an ExecStopPost:

...

ExecStopPost=/bin/bash "/usr/local/sbin/svcstop.sh"

Then create this script at /usr/local/sbin/svcstop.sh:

...

rmt:/etc/systemd/system # cat /usr/local/sbin/svcstop.sh #!/bin/bash # # Script to email on service stop # intended to be run by a systemd service

JRNL="$(/usr/bin/journalctl -u rmt-server-mirror.service -g 'WARN' --since yesterday)"

You should be able to collect messages for this exact invocation using journalctl -u rmt-server-mirror.service -g 'WARN' INVOCATION_ID=INVOCATION_ID

...

EMAIL="<my email address>" S1="Email from rmt, successful" S2="Email from rmt, failure"

if [[ $EXIT_STATUS == 0 ]]; then         SUBJECT="$S1" else         SUBJECT="$S2" fi

# the mailx option sendwait prevents it from forking, enabling systemd to manage it /usr/bin/mailx -Ssendwait -s "$SUBJECT" "$EMAIL" <<< "$JRNL"

exit 0