systemd timers and MAILTO ?
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? -- Per Jessen, Zürich (20.9°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On Sun, 7 May 2023 11:55, Per Jessen <per@...> 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) - Yamaban.
Yamaban wrote:
On Sun, 7 May 2023 11:55, Per Jessen <per@...> 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
Per Jessen wrote:
Yamaban wrote:
On Sun, 7 May 2023 11:55, Per Jessen <per@...> 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. -- Per Jessen, Zürich (22.0°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 <per@...> 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
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.
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, Zürich (20.8°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
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
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. loginctl enable-linger
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
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. Unless it is an entertainment, as me with the firewalld. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
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
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. I prefer jobs under /etc/cron*, too.
That is annoying and means extra work when doing backups. Second, same reason why we are moving toward systemd timers on the system side.
I'm not moving towards systemd timers, I do not see the advantage... -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
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 2023-05-07 23:37, Per Jessen wrote:
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.
Ah. So you want everything inside home. Including temp. I wonder if cron could be coached to keep tabs inside home instead. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On Sun, 07 May 2023 15:55:33 +0200 Per Jessen <per@opensuse.org> 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.
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)
If it includes the use of MAILTO, that would be very interesting. I'll have to have a look. Sofar, MAILTO seems to be a major hurdle. -- Per Jessen, Zürich (14.1°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
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
On Mon, 08 May 2023 10:58:03 +0200 Per Jessen <per@opensuse.org> wrote:
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
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."
There is a reference to systemd-cron https://aur.archlinux.org/packages/systemd-cron (
which you already found?
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.
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.
Dave Howorth wrote:
On Mon, 08 May 2023 10:58:03 +0200 Per Jessen <per@opensuse.org> 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:
systemd-generator-cron2timer .
Hmm, that didn't go well: office24:/var/log # zypper in systemd-generator-cron2timer Loading repository data... Reading installed packages... Resolving package dependencies... Problem: the to be installed systemd-generator-cron2timer-0-1.1.noarch conflicts with 'cronie' provided by the installed cronie-1.6.1-91.2.x86_64 Solution 1: Following actions will be done: deinstallation of cronie-1.6.1-91.2.x86_64 deinstallation of cron-4.2-91.2.x86_64 Solution 2: do not install systemd-generator-cron2timer-0-1.1.noarch -- Per Jessen, Zürich (21.0°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
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}
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 Mon, 08 May 2023 10:58:03 +0200 Per Jessen <per@opensuse.org> wrote:
Dave, do you have a URL for that?
edit: just to add that another useful-looking page is https://opensource.com/article/20/7/systemd-timers
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 <per@...> 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
On Sun, 7 May 2023 13:52:53 +0200 (CEST) Yamaban <foerster@lisas.de> wrote:
On Sun, 7 May 2023 11:55, Per Jessen <per@...> 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)
- Yamaban.
FWIW there's a typo. The DESCRIPTION starts "systemd-mail-status" :(
participants (6)
-
Andrei Borzenkov -
Carlos E. R. -
Dave Howorth -
G McAlister -
Per Jessen -
Yamaban