Pesan "dibunuh" dari cron.daily, tetapi tidak ketika dijalankan dari baris perintah

1

Pada Fedora 17, saya memasukkan file /etc/cron.dailydengan konten berikut:

cd /
su dstahlke /home/dstahlke/bin/anacron-daily.sh
exit 0

Untuk beberapa alasan, saya mendapatkan email setiap hari yang baru saja dikatakan

/etc/cron.daily/dstahlke-daily:

 ...killed.

Saya mencoba dengan dan tanpa exit 0baris di atas (saya perhatikan bahwa beberapa skrip sistem memiliki itu dan yang lainnya tidak, saya tidak yakin dengan tujuannya). Menjalankan /etc/cron.daily/dstahlke-dailydari baris perintah sebagai root tidak menghasilkan ...killedpesan. Selain pesan, semuanya tampaknya berfungsi dengan baik. Menempatkan set -xdalam skrip di atas, serta dalam /home/dstahlke/bin/anacron-daily.shskrip menunjukkan bahwa ...killedpesan terjadi tepat setelah skrip terakhir berakhir (atau mungkin tepat setelah perintah su selesai).

Apa yang menyebabkan ...killedpesan?

Atau, adakah cara yang lebih dapat diterima untuk membuat anacron menjalankan skrip pengguna setiap hari? Saya pikir menempatkan ini /etc/cron.dailyakan membantu sistem mengoordinasikan semua tugas sehari-hari daripada berpotensi menjalankan tugas saya bersamaan dengan tugas-tugas sistem.

Dan Stahlke
sumber
Pertanyaan ini sudah lama menghilang ke dalam tumbleweeds, tapi saya ingin memberi petunjuk. Saya mendapatkan pesan "... terbunuh" terlepas dari apa yang dijalankan su. Jadi, bahkan "su dstahlke ls" memberikan pesan. Saya mencoba menggunakan sudo alih-alih su, tetapi tidak akan berjalan tanpa terminal.
Dan Stahlke
Saya juga mendapatkan pesan ini, dan saya sangat ingin tahu apa alasannya.
hlovdal

Jawaban:

2

Saya melakukan penyelidikan lebih lanjut, dan menemukan bahwa ...killedmemang dicetak oleh suprogram, meskipun hasil cetak tidak berasal dari proyek coreutils hulu, tetapi diperkenalkan oleh coreutils-8.5-pam.patch dalam rpm sumber. Ada beberapa sejarah tentang asal-usul untuk menambahkan ini di bugzilla ( 622700 , 597928 dan 240117 ).

Bagian yang relevan dari kode tersebut adalah

static sig_atomic_t volatile caught_signal = false;
...
/* Signal handler for parent process.  */
static void
su_catch_sig (int sig)
{
  caught_signal = true;
}

...

static void
create_watching_parent (void)
{
  ...
  sigfillset (&ourset);
  if (sigprocmask (SIG_BLOCK, &ourset, NULL))
    {
      error (0, errno, _("cannot block signals"));
      caught_signal = true;
    }
  if (!caught_signal)
    {
       ...
       action.sa_handler = su_catch_sig;
       ...
         || sigaction (SIGTERM, &action, NULL)
 ...
  if (caught_signal)
    {
      fprintf (stderr, _("\nSession terminated, killing shell..."));
      kill (child, SIGTERM);
    }

  cleanup_pam (PAM_SUCCESS);

  if (caught_signal)
    {
      sleep (2);
      kill (child, SIGKILL);
      fprintf (stderr, _(" ...killed.\n"));
    }
  exit (status);
}

Jadi dalam beberapa cara (baik secara langsung / tidak langsung terkait dengan cleanup_pam atau tidak terkait) proses induk menerima SIGTERM antara tes kedua terakhir dan terakhir jika, dan dengan demikian hanya mencetak ...killedpesan yang jelas seharusnya merupakan kelanjutan dari fprintf di atas.

Semua dalam semua yang menggunakan ganda caught_signalsebagai penangan sinyal asinkron berarti dan sebagai variabel kontrol aliran lokal di dalam fungsi terasa seperti hack sangat kotor dan saya tidak suka kode. Saya menguji dengan memisahkan itu dan memperkenalkan variabel boolean kill_child untuk digunakan dalam tubuh fungsi dan kemudian memiliki

  if (caught_signal)
    {
kill_child:
      kill_child = true;
      status = 1;
    }

  if (kill_child) {
    {
      fprintf (stderr, _("\nSession terminated, killing shell..."));
      kill (child, SIGTERM);
    }

  cleanup_pam (PAM_SUCCESS);

  if (kill_child)
    {
      sleep (2);
      kill (child, SIGKILL);
      fprintf (stderr, _(" ...killed.\n"));
    }
  exit (status);
}

di akhir fungsi. Dengan modifikasi itu saya tidak lagi mendapat ....killedspam dari anacron.


Jadi penjelasan panjang, dan mungkin informasi lebih banyak dari yang Anda butuhkan. Namun. Saya juga menemukan lebih banyak lagi, yang merupakan kabar baik bagi Anda karena Anda tidak perlu melakukan modifikasi lokal pada paket coreutils. Untuk kasus seperti menjalankan su dari cron Anda seharusnya menjalankan program runuser sebagai gantinya . Ini semacam berita "buruk" bagi saya karena itu membuat temuan saya di atas kurang penting, tetapi juga baik :).

hlovdal
sumber
Luar biasa, terima kasih banyak! Menggunakan runuser berfungsi dengan baik dan menyelamatkan saya dari email cron setiap pagi.
Dan Stahlke