Pertanyaan Siapa lagi yang mengalami tingkat tinggi server Linux crash selama hari kedua lompatan?


* CATATAN: jika server Anda masih memiliki masalah karena kernel yang membingungkan, dan Anda tidak dapat melakukan reboot - solusi paling sederhana yang diusulkan dengan gnu tanggal yang diinstal pada sistem Anda adalah: tanggal -sekarang. Ini akan mereset variabel "time_was_set" internal kernel dan memperbaiki looping futx CPU di java dan perangkat userspace lainnya. Saya telah menempatkan perintah ini pada sistem saya sendiri dan memastikannya melakukan apa yang tertulis di kaleng *

POSTMORTEM

Anticlimax: satu-satunya hal yang mati adalah tautan VPN (openvpn) saya ke klaster, jadi ada beberapa detik yang menarik sementara itu kembali mapan. Segala sesuatu yang lain baik-baik saja, dan memulai ntp berjalan dengan bersih setelah detik kabisat berlalu.

Saya telah menulis pengalaman lengkap saya hari ini http://blog.fastmail.fm/2012/07/03/a-story-of-leaping-seconds/

Jika Anda melihat blog Marco di http://my.opera.com/marcomarongiu/blog/2012/06/01/an-humble-attempt-to-work-around-the-leap-second - dia memiliki solusi untuk mengubah waktu secara bertahap selama 24 jam menggunakan ntpd -x untuk menghindari lompatan 1 detik. Ini adalah metode pencoretan alternatif untuk menjalankan infrastruktur ntp Anda sendiri.


Baru hari ini, Sabtu 30 Juni 2012 - dimulai segera setelah awal hari GMT. Kami telah memiliki beberapa server di berbagai pusat data karena dikelola oleh tim yang berbeda semuanya menjadi gelap - tidak menanggapi ping, layar kosong.

Mereka semua menjalankan Debian Squeeze - dengan segala sesuatu mulai dari kernel stok hingga build khusus 3.2.21. Sebagian besar adalah blade Dell M610, tetapi saya baru saja kehilangan Dell R510 dan departemen lain juga kehilangan mesin dari vendor lain. Ada juga IBM x3550 yang lebih tua yang jatuh dan yang saya pikir mungkin tidak terkait, tetapi sekarang saya bertanya-tanya.

Satu crash yang saya dapatkan dari screen dump dari kata:

[3161000.864001] BUG: spinlock lockup on CPU#1, ntpd/3358
[3161000.864001]  lock: ffff88083fc0d740, .magic: dead4ead, .owner: imapd/24737, .owner_cpu: 0

Sayangnya semua baling-baling semua konon telah dikonfigurasi kdump, tetapi mereka mati begitu keras sehingga kdump tidak memicu - dan mereka telah mengosongkan konsol dihidupkan. Saya telah menonaktifkan konsol kosong sekarang, jadi semoga saja saya mendapat lebih banyak informasi setelah kecelakaan berikutnya.

Hanya ingin tahu apakah itu benang merah atau "hanya kita". Ini benar-benar aneh bahwa mereka unit yang berbeda di pusat data yang berbeda dibeli pada waktu yang berbeda dan dijalankan oleh admin yang berbeda (saya menjalankan FastMail.FM) ... dan sekarang bahkan perangkat keras vendor yang berbeda. Sebagian besar mesin yang jatuh sudah berminggu-minggu / bulan dan menjalankan kernel seri 3.1 atau 3.2.

Kecelakaan terbaru adalah mesin yang hanya naik sekitar 6 jam dengan menjalankan 3.2.21.

THE WORKAROUND

Ok orang, begini cara saya bekerja di sekitarnya.

  1. menonaktifkan ntp: /etc/init.d/ntp stop
  2. dibuat http://linux.brong.fastmail.fm/2012-06-30/fixtime.pl (kode dicuri dari Marco, lihat posting blog di komentar)
  3. berlari fixtime.pl tanpa argumen untuk melihat bahwa ada set kabisat kedua
  4. berlari fixtime.pl dengan argumen untuk menghapus detik kabisat

CATATAN: tergantung pada adjtimex. Saya telah menaruh salinan pemerasan adjtimex biner di http://linux.brong.fastmail.fm/2012-06-30/adjtimex - Ini akan berjalan tanpa ketergantungan pada sistem 64 bit peretasan. Jika Anda memasukkannya ke dalam direktori yang sama fixtime.pl, itu akan digunakan jika sistem tidak ada. Tentunya jika Anda tidak menekan 64-bit ... cari sendiri.

Saya akan mulai ntp lagi besok.

Seperti yang disarankan oleh pengguna anonim - alternatif untuk berlari adjtimex adalah hanya mengatur waktu sendiri, yang mungkin juga menghapus penghitung leapecond.


366
2018-06-30 16:15




Ada lompatan detik hari ini, tanggal 30. Saya ragu-ragu untuk menyiratkan bahwa itu adalah masalah Anda, tetapi saya akan memperhatikan mesin Debian saya secara dekat. - jscott
sejak pagi Kami telah kehilangan setidaknya 9 kotak pemerasan debian yang berbeda dari berbagai vendor yang semuanya menjalankan stok kernel 2.6.32. kami belum bisa mendapatkan dump kecelakaan karena konsol kosong juga ... - kargig
lkml memposting tentang ini lkml.indiana.edu/hypermail/linux/kernel/1203.1/04598.html - Daniel S. Sterling
Terima kasih telah melaporkan ini! Saya sekarang menatap server saya sangat, sangat erat. - Janne Pikkarainen
Benang LKML menunjukkan itu date -s "`date`" membantu - itu pasti membantu saya. - Pointy


Jawaban:


Ini disebabkan oleh livelock ketika ntpd memanggil adjtimex (2) untuk memberi tahu kernel untuk memasukkan detik kabisat. Lihat posting lkml http://lkml.indiana.edu/hypermail/linux/kernel/1203.1/04598.html

Red Hat juga harus memperbarui artikel KB mereka. https://access.redhat.com/knowledge/articles/15145

UPDATE: Red Hat memiliki artikel KB kedua hanya untuk masalah ini di sini: https://access.redhat.com/knowledge/solutions/154713 - artikel sebelumnya adalah untuk masalah yang sebelumnya tidak berhubungan

Pekerjaan ini hanya mematikan ntpd. Jika ntpd telah mengeluarkan panggilan adjtimex (2), Anda mungkin perlu menonaktifkan ntpd dan reboot agar 100% aman.

Ini mempengaruhi RHEL 6 dan distro lain yang menjalankan kernel baru (lebih baru dari sekitar 2.6.26), tetapi tidak RHEL 5.

Alasan ini terjadi sebelum detik kabisat sebenarnya dijadwalkan untuk terjadi adalah bahwa ntpd memungkinkan kernel menangani detik kabisat pada tengah malam, tetapi perlu memperingatkan kernel untuk memasukkan detik kabisat sebelum tengah malam. ntpd oleh karena itu panggilan adjtimex (2) kadang-kadang selama hari lompatan kedua, pada titik mana bug ini dipicu.

Jika Anda memasang adjtimex (8), Anda dapat menggunakan skrip ini untuk menentukan apakah flag 16 sudah diatur. Flag 16 adalah "memasukkan lompatan kedua":

adjtimex -p | perl -p -e 'undef $_, next unless m/status: (\d+)/; (16 & $1) && print "leap second flag is set:\n"'

MEMPERBARUI:

Red Hat telah memperbarui artikel KB mereka untuk dicatat: "RHEL 6 pelanggan dapat dipengaruhi oleh masalah yang diketahui yang menyebabkan NMI Watchdog mendeteksi hang saat menerima pengumuman leapsec NTP. Masalah ini sedang ditangani secara tepat waktu. Jika sistem Anda menerima pengumuman leapsecond dan tidak mengalami masalah ini, maka mereka tidak lagi terpengaruh. "

PEMBARUAN: Bahasa di atas dihapus dari artikel Red Hat; dan solusi KB kedua ditambahkan dengan merinci masalah kerusakan adjtimex (2): https://access.redhat.com/knowledge/solutions/154713

Namun, perubahan kode dalam posting LKML oleh IBM Engineer John Stultz mencatat mungkin juga ada jalan buntu ketika detik kabisat sebenarnya diterapkan, sehingga Anda mungkin ingin menonaktifkan detik kabisat dengan me-reboot atau menggunakan adjtimex (8) setelah menonaktifkan ntpd.

UPDATE AKHIR:

Yah, saya bukan pengembang kernel, tetapi saya meninjau kembali patch John Stultz di sini: https://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=6b43ae8a619d17c4935c3320d2ef9e92bdeed05d

Jika saya membacanya saat ini, saya salah tentang ada kebuntuan lain ketika detik kabisat diterapkan. Itu sepertinya pendapat Red Hat juga, berdasarkan entri KB mereka. Namun, jika Anda telah menonaktifkan ntpd, tetap nonaktifkan selama 10 menit, sehingga Anda tidak menekan kebuntuan ketika ntpd memanggil adjtimex (2).

Kami akan mencari tahu apakah ada bug lebih lanjut segera :)

PEMBARUAN KEDUA PASCA-LEAP:

Saya menghabiskan beberapa jam terakhir membaca kode kernel ntpd dan pre-patch (buggy), dan sementara saya mungkin salah di sini, saya akan mencoba menjelaskan apa yang saya pikir sedang terjadi:

Pertama, ntpd memanggil adjtimex (2) sepanjang waktu. Ini melakukan ini sebagai bagian dari "loop filter clock", yang didefinisikan dalam local_clock di ntp_loopfilter.c. Anda dapat melihat kode itu di sini: http://www.opensource.apple.com/source/ntp/ntp-70/ntpd/ntp_loopfilter.c (dari ntp versi 4.2.6).

Filter clock loop berjalan cukup sering - ini berjalan setiap kali ntpd mencari tahu server upstreamnya, yang secara default adalah setiap 17 menit atau lebih. Bit yang relevan dari filter loop clock adalah:

if (sys_leap == LEAP_ADDSECOND)
    ntv.status |= STA_INS;

Lalu:

ntp_adjtime(&ntv)

Dengan kata lain, pada hari-hari ketika ada detik kabisat, ntpd menyetel tanda "STA_INS" dan memanggil adjtimex (2) (melalui portabilitas-pembungkusnya).

Panggilan sistem itu menuju ke kernel. Berikut kode kernel yang relevan: https://github.com/mirrors/linux/blob/a078c6d0e6288fad6d83fb6d5edd91ddb7b6ab33/kernel/time/ntp.c

Codepath kernel kira-kira seperti ini:

  • baris 663 - mulai dari rutinitas do_adjtimex.
  • baris 691 - batalkan timer lompatan detik yang ada.
  • line 709 - ambil spinlock ntp_lock (kunci ini terlibat dalam kemungkinan crash livelock)
  • baris 724 - panggil process_adjtimex_modes.
  • baris 616 - panggil process_adj_status.
  • baris 590 - mengatur variabel global time_status, berdasarkan bendera yang ditetapkan dalam panggilan adjtimex (2)
  • baris 592 - periksa variabel global time_state. dalam banyak kasus, hubungi ntp_start_leap_timer.
  • baris 554 - periksa variabel global time_status. STA_INS akan diatur, jadi tetapkan time_state ke TIME_INS dan panggil hrtimer_start (fungsi kernel lain) untuk memulai timer kedua kabisat. dalam proses pembuatan timer, kode ini mengambil xtime_lock. jika ini terjadi ketika CPU lain sudah mengambil xtime_lock dan ntp_lock, kemudian kernel livelock. inilah mengapa John Stultz menulis patch untuk menghindari penggunaan hrtimers. Inilah yang menyebabkan masalah semua orang hari ini.
  • baris 598 - jika ntp_start_leap_timer tidak benar-benar memulai waktu lompatan, set time_state ke TIME_OK
  • baris 751 - dengan asumsi kernel tidak livelock, tumpukan dibatalkan dan spinlock ntp_lock dilepaskan.

Ada beberapa hal yang menarik di sini.

Pertama, baris 691 membatalkan timer yang ada setiap kali adjtimex (2) dipanggil. Kemudian, 554 menciptakan ulang pengatur waktu itu. Ini berarti setiap kali ntpd menjalankan filter loop clock-nya, kode buggy dipanggil.

Oleh karena itu saya percaya Red Hat salah ketika mereka mengatakan bahwa sekali ntpd telah menetapkan bendera kabisat kedua, sistem tidak akan crash. Saya percaya setiap sistem menjalankan ntpd memiliki potensi untuk livelock setiap 17 menit (atau lebih) untuk periode 24 jam sebelum lompatan-kedua. Saya percaya ini juga dapat menjelaskan mengapa begitu banyak sistem jatuh; satu kali kemungkinan tabrakan akan jauh lebih kecil kemungkinannya dibandingkan dengan 3 peluang per jam.

UPDATE: Dalam solusi KB Red Hat di https://access.redhat.com/knowledge/solutions/154713 , Insinyur Red Hat memang sampai pada kesimpulan yang sama (bahwa menjalankan ntpd akan terus menerus menekan kode buggy). Dan memang mereka melakukannya beberapa jam sebelum saya melakukannya. Solusi ini tidak terkait dengan artikel utama di https://access.redhat.com/knowledge/articles/15145 , jadi saya tidak menyadarinya sampai sekarang.

Kedua, ini menjelaskan mengapa sistem yang dimuat lebih cenderung crash. Sistem yang dimuat akan menangani lebih banyak interupsi, menyebabkan fungsi kernel "do_tick" dipanggil lebih sering, memberi lebih banyak kesempatan bagi kode ini untuk menjalankan dan mengambil ntp_lock ketika pengatur waktu dibuat.

Ketiga, adakah kemungkinan sistem crash ketika leap-second benar-benar terjadi? Saya tidak tahu pasti, tapi mungkin ya, karena timer yang menyala dan benar-benar mengeksekusi penyesuaian leap-second (ntp_leap_second, on line 388) juga mengambil spinlock ntp_lock, dan memiliki panggilan ke hrtimer_add_expires_ns. Saya tidak tahu apakah panggilan itu mungkin juga dapat menyebabkan livelock, tetapi tampaknya tidak mungkin.

Akhirnya, apa yang menyebabkan bendera leap-second dinonaktifkan setelah lompatan detik telah berjalan? Jawabannya ada ntpd berhenti pengaturan bendera kabisat-kedua di beberapa titik setelah tengah malam ketika memanggil adjtimex (2). Karena bendera tidak disetel, pemeriksaan pada jalur 554 tidak akan benar, dan tidak ada pengatur waktu akan dibuat, dan jalur 598 akan mereset variabel global time_state menjadi TIME_OK. Ini menjelaskan mengapa jika Anda mencentang bendera dengan adjtimex (8) tepat setelah detik kabisat, Anda masih akan melihat bendera kabisat-kedua ditetapkan.

Singkatnya, saran terbaik untuk hari ini tampaknya adalah yang pertama yang saya berikan setelah semua: menonaktifkan ntpd, dan menonaktifkan bendera leap-second.

Dan beberapa pemikiran terakhir:

  • tidak ada vendor Linux yang memperhatikan tambalan John Stultz dan mengaplikasikannya ke kernel mereka :(
  • mengapa John Stultz tidak memberitahukan beberapa vendor yang dibutuhkan? mungkin kesempatan livelock tampak cukup rendah sehingga membuat kebisingan tidak dibenarkan.
  • Saya pernah mendengar laporan tentang proses Java yang terkunci atau berputar ketika detik kabisat diterapkan. Mungkin kita harus mengikuti petunjuk Google dan memikirkan kembali bagaimana kita menerapkan lompatan detik ke sistem kita: http://googleblog.blogspot.com/2011/09/time-technology-and-leaping-seconds.html

06/02 Pembaruan dari John Stultz:

https://lkml.org/lkml/2012/7/1/203

Postingan ini berisi langkah demi langkah tentang mengapa lompatan kedua menyebabkan timer futex berakhir secara prematur dan terus menerus, memacu beban CPU.


322
2018-06-30 19:56



Terima kasih atas jawaban yang luar biasa. Jadi sisa server kami sedang menunggu untuk crash. Menyenangkan. Rolling restart di sini kami datang! - Bron Gondwana
Bagaimana saya tahu jika adjtimex telah diterbitkan, apakah kernel mencetak sesuatu di dmesg? Kesempatan apa yang ada sehingga sistem yang tidak crash sebelum mematikan ntpd akan crash? - Hubert Kario
Hubert: jalankan "adjtimex" (biasanya dikemas secara terpisah) dan cari bendera 16 untuk menunjukkan lompatan detik yang tertunda. - Dominic Cleal
Anda akan membenci topi rep. - Wesley
@WesleyDavid: Jangan khawatir, topi rep akan disetel ulang pada tengah malam UTC. Mungkin. - mmyers


Ini memukul kami dengan keras. Setelah memulai ulang banyak host kami, berikut ini ternyata menjadi sangat sederhana dan sepenuhnya efektif tanpa restart host:

/etc/init.d/ntp stop
ntpdate 0.us.pool.ntp.org
/etc/init.d/ntp start

Semua yang diperlukan adalah mengatur ulang jam sistem. Sheesh. Apa yang telah saya berikan untuk mengetahui ini enam jam yang lalu.


33
2017-07-01 07:49



date -s "`date`" bekerja untukku. - Pointy
@DeanB: Saya memposting pukul 3 pagi UTC yang mengatur ulang jam melakukan trik, sayangnya butuh waktu lama untuk dimoderasi. Kami juga memulai reboot server - Gregor


Program C sederhana yang membersihkan bit kedua kabisat di bidang status waktu kernel:

#include <sys/timex.h>
#include <string.h>
#include <stdio.h>

int main(int argc, char **argv) {
    struct timex txc;
    int ret;

    (void) argc;
    (void) argv;

    bzero(&txc, sizeof(txc));
    txc.modes = 0;  /* fetch */
    ret = adjtimex(&txc);
    if (ret < 0) {
        perror("adjtimex (get)");
        return 1;
    }

    txc.modes = ADJ_STATUS;
    txc.status &= ~16;
    ret = adjtimex(&txc);
    if (ret < 0) {
        perror("adjtimex (set)");
        return 1;
    }

    return 0;
}

Simpan sebagai lsec.c, dikompilasi dengan gcc -Wall -Wextra -o lsec lsec.c dan jalankan sebagai root.

Anda mungkin ingin berhenti ntpd sebelum menjalankannya, dan restart ntpd setelah detik kabisat.


24
2018-06-30 23:13



Apa yang terjadi (void) argc; menyelesaikan? Diamkan peringatan untuk variabel yang tidak digunakan? Tidak akan menggunakan int main() melakukan hal yang sama? Tidak mencoba menjadi seorang pedant, saya benar-benar penasaran. - gparent


Tampaknya postmortem ./lsec tidak memiliki efek.

Apa yang kami lihat adalah banyak proses softirqd memakan CPU (biasanya linier dengan beban proses java)

Apa yang berfungsi untuk memperbaiki POSTMORTEM dengan detik kabisat yang sudah diterapkan oleh ntp adalah sebagai berikut:

Tampaknya cukup untuk sekadar masalah:

export LANG="en_EN"; date -s "`date`"

Ini harus mengurangi beban tanpa ntpd restart atau reboot. Atau Anda dapat menerbitkan:

apt-get install ntpdate
/etc/init.d/ntpd stop; ntpdate pool.ntp.org; /etc/init.d/ntpd start

18
2017-07-01 03:41



Mengapa sntp -s dan tidak ntpdate? - errordeveloper
ntpdate hanyalah pembungkus untuk sntp di sini, tentu tidak masalah untuk menggunakan ntpdate juga. - Gregor
ah saya benar-benar merindukan ada paket ntpdate untuk memeras di mana itu sebenarnya sebuah biner. Saya telah mengedit posting saya untuk memasukkan ini. - Gregor
Saya telah mendengar laporan serupa tentang memperbaiki masalah ini juga (seperti menggunakan date -s). Kedengarannya seperti perbaikan hanya membutuhkan pengaturan waktu sistem bukannya slewing itu (perilaku ntpd default ketika offset kecil). Saya menduga pengaturan waktu menyebabkan mekanisme pemeliharaan waktu internal kernel untuk mereset sendiri. - Patrick
Penggunaan java apps CPU saya juga melonjak (dengan jumlah waktu CPU yang tinggi dihabiskan di softirqd), ini memperbaikinya. - Hubert Kario


http://my.opera.com/marcomarongiu/blog/2012/03/12/no-step-back nampaknya mengindikasikan bahwa kernel Debian squeeze tidak akan menangani leap second.

Thread ini di comp.protocols.tim.ntp menarik, juga: https://groups.google.com/forum/?fromgroups#!topic/comp.protocols.time.ntp/KSflIgjUdPE

Yang mengatakan, detik kabisat belum terjadi: 23:59:60 UTC

Akhirnya, https://access.redhat.com/knowledge/articles/15145 memiliki beberapa hal berikut untuk mengatakan: "Ketika detik kabisat terjadi, kernel mencetak pesan ke log sistem. Ada kemungkinan bahwa pencetakan pesan ini dapat menyebabkan kernel crash di Red Hat Enterprise Linux."


17
2018-06-30 18:47



Tetapi kernel 3.2.21 seharusnya, mungkin - yang merupakan salah satu dari paling tidak salah satu dari mesin yang mogok dijalankan - Bron Gondwana
Pada beberapa mesin yang diindikasikan Bron kami sebenarnya telah meluncurkan perbaikan yang seharusnya menangani detik kabisat yang akan datang dengan tepat. - cosimo
dapatkah Anda memposting tempat tertentu agar orang lain dapat meninjau / menyarankan ide / mencoba? - kargig
Saya tidak memperbaikinya ... Saya hanya mengumpulkan info. Mungkin seharusnya menempatkan ini sebagai komentar terhadap pertanyaan asli. - Luca Filipozzi
my.opera.com/marcomarongiu/blog/2012/06/01/… berisi detail lebih lanjut tentang memperbaikinya - Bron Gondwana