![](https://seccdn.libravatar.org/avatar/e85bb1c491d4dd3ebd96110df58f8739.jpg?s=120&d=mm&r=g)
Am Dienstag, 13. Dezember 2022, 11:10:59 CET schrieb G McAlister:
On 12/12/2022 12:31, Axel Braun wrote:
Ho,
Am Sonntag, 11. Dezember 2022, 11:21:35 CET schrieb G McAlister:
Try setting the binary option sendwait to the mailx command:
MAILER="mailx -Ssendwait -Sverbose -Ssmtp-use-starttls -Ssmtp-auth=login -Ssmtp-auth-user="myaddress@gmx.de" -Ssmtp-auth-password="TopSecret" " ^^^^^^^^^^ That gives now a sentence more:
Dez 12 12:24:36 systemd[1]: transactional-update.service: Consumed 16.670s CPU time. Dez 12 12:24:36 systemd[1]: transactional-update.service: Triggering OnSuccess= dependencies. Dez 12 12:24:36 systemd[1]: Created slice Slice /system/systemd-status-mail. Dez 12 12:24:36 systemd[1]: systemd-status-mail@transactional-update.service.service: multiple trigger source candidates for exit status propagation (transactional-update.service, transactional-update.service), skipping. Dez 12 12:24:36 systemd[1]: Starting Send status mail for transactional-update.service... Dez 12 12:24:36 systemd[1]: systemd-status-mail@transactional-update.service.service: Deactivated successfully. Dez 12 12:24:36 systemd[1]: Finished Send status mail for transactional-update.service.
...but I have no idea what to do with his information. Not sure if it was due to manual trigger of the t-u.service, but should not
Cheers Axel
Can you confirm that the /etc/default/systemd-status-mail configuration is actually being picked up in the systemd-status-mail unit?
My best guess is 'yes', as it changed the error message after changing the configuration entry from mailx to mailx + command line parameters.
My experience with mailx and systemd has been that that systemd cleans up the service as soon as mailx has kicked off a sendmail request, killing the sendmail process before it completes - hence no mail. I solved this by setting the sendwait binary option to mailx, so thought it might be the same explanation here. The symptoms are the same.
Addting the sendwait changed the error to "multiple trigger source candidates for exit status propagation (transactional-update.service, transactional-update.service), skipping." so there is a change in behaviour. No idea how to tackle this, though. Will ask the author what he thinks... @carlos - I wanted to avoid to set-up a MTW on the Raspi as well.....but yes, that would be an alternative... Thanks Axel -- Dr.-Ing. Axel K. Braun M: +49.173.7003.154 T: @coogor Matrix/Elements: @docb:matrix.org PGP Fingerprint: 2E7F 3A19 A4A4 844A 3D09 7656 822D EB64 A3BA 290D Public Key available at http://www.axxite.com/axel.braun@gmx.de.asc Personal Freedom starts with free/libre Software ThinkPad X1 Extreme running openSUSE Tumbleweed 20221209