Cek yang tidak bisa gagal: lima false positive dari seminggu otomasi Mac

Satu aturan bisa menghemat hampir seminggu waktu kami. Sebelum memercayai sebuah cek, tanyakan apa yang ia cetak saat sesuatunya rusak. Jika jawabannya "hal yang sama", Anda tidak punya cek. Anda punya hiasan bertuliskan OK.

Berikut lima yang kami temukan dalam satu minggu. Semuanya di macOS, semuanya di otomasi yang sudah berjalan tanpa keluhan berbulan-bulan. Masing-masing memberi jawaban salah dengan yakin. Dan masing-masing membuat orang sibuk memperbaiki sesuatu yang tidak rusak.

1. Update yang sebenarnya tidak berjalan

Satu mesin terasa lambat kembali setelah reboot. Perintah pgrep -f softwareupdate menemukan kecocokan. Jadi script melaporkan ada software update yang sedang berjalan, dan kami menunggu.

Tidak ada update. softwareupdated adalah daemon yang selalu ada di setiap Mac, dan pencocokan substring menemukannya entah ada kegiatan atau tidak. Pemilik mesin menangkapnya dengan pertanyaan sederhana: seharusnya tidak ada update, jadi apa masalahnya? Cek itu tidak punya jawaban, karena memang tidak pernah punya.

Perbaikannya adalah mencari jejak yang ditinggalkan update yang berjalan. Unduhan yang sedang berlangsung atau aktivitas disk yang terus-menerus adalah bukti. Nama proses yang selalu ada bukan bukti.

2. Xcode yang tersalin dalam nol detik

Kami menyalin Xcode antar mesin dengan mengalirkan archive tar lewat SSH. Satu kali, aliran itu lewat laptop yang kehabisan memori. Sisi pengirim mati. tar -xf - di sisi penerima membaca stream kosong, tidak mengekstrak apa pun, dan keluar dengan kode nol. Script mencetak XCODE_COPIED.

Tidak ada satu byte pun yang berpindah. Exit code-nya jujur soal tugas yang diberikan ke tar, yaitu mengekstrak apa pun yang datang. Tidak ada yang datang.

# what we checked
tar -xf - -C /Applications && echo XCODE_COPIED

# what we should have checked
du -sh /Applications/Xcode.app          # 3.8G, or it did not happen
/Applications/Xcode.app/Contents/Developer/usr/bin/xcodebuild -version

3. Izin yang dilaporkan sudah diberikan

macOS mengunci perekaman layar di balik hak yang hanya bisa diberikan oleh manusia atau profil MDM. Tool kickstart milik Apple mencetak peringatan yang jelas saat hak itu tidak ada. Probe kami mencari peringatan itu. Karena tidak menemukannya, probe melaporkan hak itu sudah diberikan.

Saat tool itu tidak punya hak sama sekali, ia tidak mencetak apa pun. Tidak ada peringatan, tidak ada apa-apa. Tidak adanya peringatan terlihat persis seperti sukses. Cerita lengkapnya ada di Mac yang menerima login Anda lalu tidak menampilkan apa-apa. Perbaikannya, berhenti menanyakan pendapat tool itu. Sebagai gantinya, ambil sampel piksel nyata dari framebuffer.

4. Desktop yang dilaporkan mati

Untuk memastikan ada pengguna yang login ke GUI, kami mengecek siapa pemilik /dev/console. Di mesin baru hasilnya root, jadi kami menyimpulkan tidak ada yang login. Lalu kami mengecek mesin pelanggan, yang penggunanya sudah login dua hari. Hasilnya juga root.

Selama sekitar sepuluh menit, desktop pelanggan yang membayar dilaporkan mati. Padahal baik-baik saja. Kepemilikan device node itu memang tidak berarti seperti yang kami kira. who menampilkan baris console hanya jika ada sesi, dan itulah yang kini dilaporkan telemetri kami.

5. Error yang ternyata konstan

Satu mesin di macOS major yang baru tidak mau auto-login. sysadminctl -autologin set dari Apple mengembalikan SACSetAutoLoginPassword error:22. OS baru, error baru, kesimpulannya terlihat jelas: rilis baru merusak auto-login lewat script.

Lalu kami menjalankan perintah yang sama di mesin sehat satu versi major di belakang, yang auto-login-nya sudah jalan berminggu-minggu. Error-nya sama. Perintah itu gagal dengan cara yang sama di sistem yang berfungsi maupun yang rusak. Jadi ia tidak membawa informasi apa pun soal keduanya. Penyebab sebenarnya ternyata kondisi sementara saat boot pertama. Diagnosis yang yakin itu salah, dan pembandingnya membantahnya dalam kurang dari semenit.

Aturannya, dan dua turunannya

Kelimanya gagal di pertanyaan pertama. Empat hari habis untuk mengejarnya. Tidak satu pun sistem di baliknya rusak seperti yang diklaim cek-cek itu.

Yang berubah

Cek layar mengambil sampel framebuffer dan menghitung warna. Cek sesi memakai who dan dikirim lewat telemetri. Jadi mesin yang berhenti di jendela login memicu peringatan, bukan terlihat sehat. Salinan diverifikasi lewat ukuran dan dengan menjalankan binary yang disalin. Dan tidak ada kegagalan yang diberi akar masalah sebelum cek yang sama dijalankan di sesuatu yang diketahui berfungsi. Tidak ada yang canggih di sini. Semuanya pertanyaan yang sama, diajukan sebelum cek ditulis, bukan setelah cek itu berbohong.