Keluarkan log latar belakang atau skrip boot

10

Saya memiliki skrip pendek yang dijalankan oleh daemon sistem untuk peristiwa tertentu. Saya tahu acara sedang terjadi dan skrip mengeksekusi, tetapi tidak melakukan apa yang saya inginkan. Anehnya, itu terjadi ketika saya menjalankannya secara manual, jadi saya sangat bingung.

Bagaimana saya mengetahui apa yang sedang terjadi? Script pada dasarnya adalah serangkaian perintah seperti ini:

/bin/foo on 3
sudo bar a

— goldilocks
sumber

Saya mengerti ini dimaksudkan sebagai tutorial tentang debugging skrip sistem, tetapi juga sedikit U&L. Saya salah membaca judul dan menyarankan "Mencatat hasil skrip sistem untuk debugging" akan membuat tujuan menjadi lebih jelas. Otak saya juga membeku ketika saya membaca foo barcontoh - contoh ini , saya lebih suka sesuatu yang terlihat lebih nyata. Saya enggan mengedit posting apa pun, jadi akan serahkan kepada Anda jika Anda pikir ini dapat diperbaiki.

— Milliways

1

@Milliways Kau benar, "sistem script" agak keliru jadi aku mengubah judulnya. Saya tidak setuju tentang hal foobar - orang perlu belajar untuk mengenali istilah umum / bahasa sehari-hari seperti yang mungkin mereka lakukan dalam budaya apa pun. Juga masih cekikikan yang baik setelah Anda menyatukan keduanya.

— goldilocks

8

Pertama, jika skrip dijalankan oleh daemon sistem dan daemon itu berjalan dengan hak akses root, Anda tidak perlu menggunakannya sudo. Ini termasuk init(dan systemd), yang termasuk rc.local. Jika daemon itu tidak berjalan dengan hak akses root, maka sudotidak akan berfungsi kecuali jika /etc/sudoersdikonfigurasi untuk mengizinkannya (dan tanpa kata sandi). Pengguna raspbian mungkin bingung dengan hal ini karena pipengguna diizinkan untuk melakukan apa saja secara default (dan jika Anda melihat /etc/sudoersAnda akan melihat bagaimana hal itu dilakukan).

Selanjutnya, Anda dapat menangkap output dari bashskrip apa pun , atau sekumpulan perintah di dalam skrip bash, dengan menjalankannya dalam subkulit seperti ini: ¹

(
    /bin/foo on 3
    sudo bar a
) &> /var/log/myTestLog.txt

The ()menunjukkan subkulit . Semua output dari apa pun di dalamnya sedang diarahkan ke /var/log/myTestLog.txtfile. Beberapa catatan:

&>adalah bashism , jadi jika skrip dieksekusi melalui shebang pada baris pertama, seharusnya #!/bin/bash, bukan hanya /bin/sh. "Bashism" hanya berfungsi di bashshell.

Ini termasuk /etc/rc.local, yang secara default digunakan /bin/sh(mis., Ya, Anda dapat dengan aman mengubahnya ke /bin/bash).
/var/logmembutuhkan hak akses root untuk menulis. Jika prosesnya tidak seperti itu, gunakan atau buat direktori yang Anda tahu bisa. Jika ragu, jika Anda dapat menguji ini tanpa harus mematikan atau menyalakan ulang sistem, gunakan /tmp, yang dapat ditulis oleh dunia (yaitu oleh siapa saja). Namun /tmptidak bertahan di sepatu bot. Ini juga merupakan partisi kecil berbasis RAM, jadi jangan menulis pertunjukan data untuknya. Ini bukan kartu SD Anda [sebenarnya pada versi Raspbian saat ini, tetapi jangan mengandalkan ini dalam praktiknya] .
&>akan menimpa apa pun di myTestLog.txt. Jika Anda ingin menambahkan log yang ada, yang mungkin merupakan ide bagus untuk tujuan debugging, gunakan &>>. Anda kemudian dapat menambahkan perintah ke awal subkulit itu seperti ini:
```
echo Starting $(date)
```
Untuk memisahkan informasi dari setiap proses. Jika Anda tidak yakin apa yang dilakukannya, coba di baris perintah.

Poin terakhir ini adalah ilustrasi yang baik dari sesuatu yang dapat Anda lakukan sehubungan dengan perintah yang tidak menghasilkan apa-apa - tetapi kebanyakan dari mereka melakukannya jika Anda memasukkan, misalnya, -vuntuk "verbose". Waspadai beberapa perintah -vberarti "cetak informasi versi". Lihat di halaman manual untuk mengetahui perintah apakah dan bagaimana ini akan bekerja (beberapa perintah juga menggunakan saklar yang berbeda dari -v).

Dengan konvensi, perintah juga mengembalikan nilai 0 saat selesai. Ini kadang-kadang disebut "status keluar" dan Anda biasanya tidak melihatnya, tetapi shell akan menunjukkannya kepada Anda echo $?. Mencoba

 ls /
 echo $?
 ls /nonexistantdir
 echo $?

Anda akan mendapatkan 0 dan 2. Jika Anda kemudian mencari di halaman manual di lsbawah "Keluar dari status", Anda akan melihat yang agak tidak spesifik, samar:

2      if serious trouble (e.g., cannot access command-line argument).

Yang mungkin atau mungkin tidak lebih baik daripada tidak sama sekali, tetapi begitulah.

Paling tidak, ini menunjukkan perintah gagal karena beberapa alasan. Status keluar juga memungkinkan Anda melakukan hal-hal seperti ini:

/bin/foo && sudo bar

Dalam &&hal ini berarti "jika perintah pertama berhasil", anggap perintah pertama menggunakan konvensi pengembalian 0 (itulah sebabnya mereka biasanya melakukannya). Jika /bin/footidak berhasil, tidak dapat ditemukan, dll., Maka sudo bartidak akan pernah terjadi.

Menggunakan kombinasi pesan logging dan eksekusi bersyarat ( &&) harus membuat Anda lebih dekat untuk mencari tahu masalah, atau setidaknya mendapatkan informasi yang mungkin berguna bagi orang lain dalam membantu Anda memecahkan masalah. Tanpa itu, yang paling sering dilakukan orang lain adalah menebak.

^{1. Anda dapat mencapai redirection output yang sama untuk seluruh skrip dari dalam dengan menggunakan:}

exec &> /var/log/myTestLog.txt

^{Di bagian atas (atau di mana saja, dan itu akan berlaku untuk semuanya berikutnya).}

— goldilocks
sumber

2

Salah satu aspek penting yang cenderung dilupakan orang ketika menjalankan skrip sebagai daemon adalah lingkungan shell, dan $PATHvariabel khususnya. Dalam contoh Anda, baris kedua bergantung pada $PATH: nama lengkapnya sudoadalah /usr/bin/sudo, dan shell pengguna Anda hanya mengetahui hal itu karena diperintahkan untuk mencari /usr/binketika mencari executable. Hal yang sama berlaku untuk bar.

Mengingat itu sudotidak diperlukan saat menjalankan skrip sebagai daemon, baris kedua Anda akan terlihat seperti:

/path/to/bar a

— Dmitry Grigoryev
sumber