Solusi 1:
Pertama, Anda memerlukan dua file:file yang dapat dieksekusi untuk mengirim email dan .service untuk memulai file yang dapat dieksekusi. Untuk contoh ini, executable hanyalah skrip shell yang menggunakan sendmail :
/usr/local/bin/systemd-email:
#!/bin/bash
/usr/bin/sendmail -t <<ERRMAIL
To: $1
From: systemd <[email protected]$HOSTNAME>
Subject: $2
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=UTF-8
$(systemctl status --full "$2")
ERRMAIL
Apa pun yang dapat dieksekusi yang Anda gunakan, mungkin diperlukan setidaknya dua argumen seperti yang dilakukan skrip shell ini:alamat tujuan pengiriman dan file unit untuk mendapatkan status. .service kami buat akan melewati argumen ini:
/etc/systemd/system/[email protected]:
[Unit]
Description=status email for %i to user
[Service]
Type=oneshot
ExecStart=/usr/local/bin/systemd-email address %i
User=nobody
Group=systemd-journal
Di mana pengguna adalah pengguna yang dikirimi email dan alamat adalah alamat email pengguna itu. Meskipun penerima di-hard-code, file unit yang akan dilaporkan diteruskan sebagai parameter instan, sehingga layanan yang satu ini dapat mengirimkan email untuk banyak unit lainnya. Pada titik ini Anda dapat memulai [email protected] untuk memverifikasi bahwa Anda dapat menerima email.
Kemudian cukup edit layanan email yang Anda inginkan dan tambahkan [email protected]%n.service ke [Unit] bagian. %n meneruskan nama unit ke template.
Sumber:wiki archlinux:penghitung waktu systemd MAILTO
Solusi 2:
Solusi yang diusulkan oleh @gf_ bekerja dengan baik untuk situasi kami yang menjalankan clickhouse di CentOS7. Clickhouse mogok secara teratur pada kami sehingga kami harus memulai ulang keduanya secara otomatis dan diberi tahu saat mulai ulang terjadi. Meskipun tampaknya sedikit kikuk untuk menambahkan layanan kedua ke systemd, hal ini diperlukan karena desain systemd.
Meskipun demikian, solusi ini, jika digabungkan dengan memulai ulang otomatis, berhenti bekerja untuk kami saat kami menerapkannya ke CentOS8. Ini karena systemd v239 yang dikirimkan dalam C8 memperkenalkan perubahan pada OnFailure= semantik bila digabungkan dengan konfigurasi non-default Restart= (Restart=on-failure dalam kasus kami). OnFailure= baru perilaku hanya memicu layanan sekali pakai jika restart gagal sepenuhnya, tidak hanya setelah crash. Perilaku yang lebih baru ini dengan senang hati akan memulai ulang layanan, tetapi kami tidak akan mendapatkan email sebagai OnFailure= tidak lagi dipanggil.
Perhatikan harapan utama kami:kami ingin systemd memulai ulang proses DAN mengirim pemberitahuan email. Pembaruan v239 membuat solusi kami sebelumnya yang dikutip oleh gf_ tidak berfungsi lagi. Untungnya kami dapat membuatnya berfungsi.
Solusi kami adalah menggunakan ExecStopPost untuk memanggil skrip pemberitahuan email. Ini berfungsi dengan baik, tetapi sekarang muncul masalah baru:pemberitahuan email dikirim saat layanan clickhouse dimulai secara normal, seperti saat memulai server. Meskipun bukan masalah besar, idealnya kami ingin mendapatkan notifikasi email hanya pada crash. Kami dapat melakukannya dengan menambahkan kode berikut ke skrip email kami:
# Don't do anything if the service intentionally stopped successfully.
if [ $SERVICE_RESULT == "success" ]; then
exit
fi
... $SERVICE_RESULT adalah variabel lingkungan yang disediakan oleh systemd ke proses target ExecStopPost . Dengan memeriksa success hasilnya, kami berasumsi bahwa pemanggilan ini berasal dari pengaktifan normal, atau penonaktifan, dan tidak melakukan apa pun. Pada nilai lainnya, seperti signal , skrip akan berlanjut saat mengirim email. Nilai yang mungkin dari variabel ini dinyatakan dalam dokumentasi.
Terima kasih kepada gf_ untuk solusi awalnya. Saya harap orang-orang menganggap pembaruan saya bermanfaat untuk CentOS8. Beberapa tautan lagi yang membantu saya:
- https://superuser.com/questions/1360346/how-to-send-an-email-alert-when-a-linux-service-has-stopped
- https://unix.stackexchange.com/questions/422933/confusing-systemd-behaviour-with-onfailure-and-restart
- https://unix.stackexchange.com/questions/197636/run-an-arbitrary-command-when-a-service-fails