Hindari pekerjaan cron pada pukul 2:00 dan 3:00 (2013)

• Tulisan yang memperingatkan tentang kesalahan pekerjaan cron yang terjadi saat transisi daylight saving time (DST) di server Linux
• Dua kali setiap tahun, saat zona waktu berubah pada Minggu dini hari pukul 2 atau 3, muncul masalah pekerjaan cron dijalankan ganda atau terlewat
• Sebagai contoh nyata, di lingkungan vixie-cron, pekerjaan antara pukul 3:00~3:01 dijalankan berulang 60 kali dengan interval 1 detik, menyebabkan kekacauan email
• Sebagai solusi, disarankan mengatur zona waktu ke UTC atau menghindari pekerjaan pada jam tersebut, serta mengembangkan scheduler open source yang lebih baik
• Contoh ini mengingatkan operator server dan engineer DevOps akan pentingnya mengelola risiko transisi zona waktu

---

Benturan antara daylight saving time dan pekerjaan cron

• Jika pekerjaan cron dijadwalkan pada Minggu dini hari pukul 2 atau 3, waktunya akan bertabrakan dengan momen transisi daylight saving time (DST) dan dapat menimbulkan kesalahan eksekusi yang tidak terduga
  • Saat DST dimulai, jam maju satu jam, dan saat berakhir, jam mundur satu jam, sehingga terjadi duplikasi atau hilangnya waktu tertentu
  • Akibatnya, pekerjaan pada rentang waktu tertentu bisa dijalankan dua kali atau bahkan tidak dijalankan sama sekali
• Terutama pekerjaan yang berjalan setiap Minggu dini hari akan terdampak oleh momen transisi DST yang terjadi 2 kali setahun
  • Biasanya berjalan normal, tetapi pada hari transisi DST bisa terjadi eksekusi berulang yang tidak normal

Kasus nyata: masalah eksekusi berulang pada vixie-cron

• Di lingkungan Linux dengan vixie-cron, pernah dilaporkan kasus saat DST dimulai di mana pekerjaan antara pukul 3:00~3:01 dijalankan sekitar 60 kali dengan interval 1 detik
  • Setiap pekerjaan saling bertabrakan dan menimbulkan kekacauan seperti banjir notifikasi email
  • Untungnya, pekerjaan tersebut tidak bersifat kritis sehingga tidak menimbulkan kerusakan sistem
• Masalah ini berasal dari struktur penjadwalan berbasis waktu cron yang sederhana
  • Cron tidak memahami perubahan zona waktu atau transisi DST, dan hanya menjalankan tugas sesuai waktu yang ditentukan

Solusi dan alternatif yang mungkin

• Cara paling sederhana adalah tidak menjadwalkan pekerjaan pada Minggu dini hari pukul 2 dan 3
  • Dengan menghindari rentang waktu itu, masalah eksekusi ganda akibat transisi DST dapat dihindari sepenuhnya
• Mengatur zona waktu server ke UTC juga merupakan alternatif yang efektif
  • UTC tidak menerapkan daylight saving time, sehingga tidak ada perubahan waktu
• Sebagai solusi yang lebih mendasar, diajukan usulan untuk mengembangkan scheduler pekerjaan yang lebih cerdas
  • Dibutuhkan alat alternatif open source yang memiliki fitur seperti pencegahan eksekusi ganda, pembatasan waktu eksekusi, dan kesadaran terhadap zona waktu

Usulan jangka panjang: menghapus daylight saving time

• Penulis mengajukan penghapusan DST di tingkat pemerintah sebagai solusi yang paling diinginkan
  • Perubahan waktu dua kali setahun menciptakan kompleksitas yang tidak perlu bagi operasi sistem maupun kehidupan manusia
• Namun selama DST masih dipertahankan, administrator sistem dan engineer DevOps harus mengambil langkah pencegahan
  • Khususnya perlu berhati-hati dalam mengelola pekerjaan yang bergantung pada waktu seperti batch otomatis, backup, dan rotasi log

Kesimpulan: prinsip penjadwalan cron yang aman

• Hindari pekerjaan pada rentang pukul 2:00~3:00 saat transisi DST
• Jika memungkinkan, gunakan operasi server berbasis UTC untuk menghilangkan masalah zona waktu
• Sadarilah keterbatasan cron dan pertimbangkan penggunaan alat penjadwalan yang lebih tangguh
• Dalam lingkungan DevOps, pengelolaan zona waktu dan jaminan keandalan otomatisasi adalah tugas yang penting

[semjei]

Saya juga selalu menghindarinya sejak mengalami masalah pada tugas yang dijadwalkan pukul 2 dini hari (kadang dijalankan dua kali, kadang tidak dijalankan sama sekali).

[GN⁺]

Komentar Hacker News

• Saya merasa DST (daylight saving time/waktu musim panas) adalah sistem yang sepenuhnya keliru
  Tidak menyelesaikan masalah apa pun dan justru hanya menimbulkan ketidaknyamanan
  Tinggal tetapkan saja waktu standar secara permanen, lalu majukan jam kerja satu jam seperti jadwal musim panas
  Misalnya toko buka pukul 6 alih-alih 7, dan tutup pukul 9 alih-alih 10
  Toh tetap ada masa penyesuaian dua kali setahun, jadi sekalian ubah sekali saja
  Saya ingin lebih banyak melihat sinar matahari setelah pulang kerja. Terutama di musim dingin, dan saya tidak peduli apakah matahari sudah terbit saat berangkat kerja
  Karena saya akan terkurung di dalam ruangan selama 9 jam, saya ingin melihat matahari saat punya waktu luang

  • Semua orang membenci DST, tetapi alternatif yang diusulkan sebenarnya sudah pernah dicoba
    Misalnya ada eksperimen DST sepanjang tahun di Amerika Serikat pada 1973–1975
    Awalnya dukungan publik tinggi karena alasan seperti penghematan energi dan penurunan kriminalitas,
    tetapi opini publik cepat memburuk akibat kecelakaan saat anak-anak berangkat sekolah di pagi yang gelap, dan akhirnya kebijakan itu dihapus
    (kutipan Wikipedia)
  • Saya bertanya-tanya, bukankah usulan untuk tidak memindahkan jam dan hanya mengubah jam operasional pada akhirnya menghasilkan efek yang sama?
    Malah terdengar seperti menginginkan pergeseran waktu yang lebih besar
  • Istilah ‘waktu musim dingin’ sebenarnya tidak ada
    Yang ada hanya waktu standar dan daylight saving time
    Ungkapan untuk selalu mempertahankan ‘waktu musim dingin’ terasa kurang menarik secara psikologis
  • DST pada dasarnya cuma solusi sementara agar sesuai dengan waktu matahari terbit
    Orang-orang ingin memulai hari saat matahari sudah terbit
    Para programmer memang dibuat repot oleh DST, tetapi saya menganggap itu masalah penanganan edge case yang harus dilakukan dengan baik
  • Perdebatan soal waktu standar versus daylight saving time pada akhirnya muncul karena kurangnya kebebasan memilih jam kerja
    Pola tidur tiap orang berbeda, jadi kalau semua bisa memilih jam kerja yang cocok, konflik seperti ini akan berkurang

• Dulu saat menyiapkan server reddit, saya mengatur semuanya ke zona waktu Arizona
  Arizona tidak memakai DST, jadi selisihnya dengan California hanya 1 jam
  Alasan tidak memakai UTC adalah karena saat membaca log, ‘lebih mudah mengurangkan 1 daripada 8’
  Sekarang timnya sudah global, jadi semuanya sudah diubah ke UTC

  • Saya pernah membuat keputusan serupa, dan belakangan susah membereskannya
    Lebih baik dari awal semua diseragamkan ke UTC
  • Tetapi seperti Arizona, selalu ada risiko definisi zona waktu berubah
    Perubahan seperti ini sering terjadi di seluruh dunia, dan dari sudut pandang pengembang aplikasi kalender, ini benar-benar merepotkan
  • Saya kesal dengan UI penampil log yang memaksa format 12/24 jam berdasarkan pengaturan bahasa browser
    Kalau seseorang memilih UTC, seharusnya diasumsikan mereka paham format YYYY-MM-DD 24 jam
  • Di Java, zona waktu default bisa diatur di tingkat JVM,
    tetapi karena masing-masing orang di organisasi mengubahnya ke PST, muncul kekacauan karena waktu di setiap log berbeda-beda
    Akhirnya seorang pemimpin turun tangan dan menyeragamkan semua aplikasi dan DB ke PST
  • Saat membaca log dalam UTC, fakta bahwa tanggal tidak ikut berganti masih terasa membingungkan
    Meski begitu, sekarang saya sudah bisa menafsirkan UTC secara naluriah

• Dulu saya pernah mengatur server perusahaan ke BST (British Summer Time) dan banyak memakai cron,
  lalu kekacauan yang sama terulang dua kali setiap tahun
  Sampai perusahaannya bangkrut pun kami tidak sempat memperbaikinya
  Pelajarannya sederhana — pakailah UTC, kecuali ada alasan khusus

  • Saya menaruh jam analog UTC di meja untuk dijadikan acuan saat melihat log
  • Ada juga kasus memakai zona waktu lokal karena pelanggan tidak berada di UTC
    Misalnya reset batas penggunaan atau batch penagihan berjalan berdasarkan waktu wilayah setempat
  • Menurut saya lebih baik jangan memakai cron itu sendiri, melainkan gunakan scheduler yang memahami data dan pengaturan pelanggan
  • Beberapa laporan memang perlu berdasarkan waktu lokal
    Misalnya laporan pukul 8 di Inggris akan bergeser dalam UTC sesuai DST
    Jadi UTC saja tidak cukup, dan informasi zona waktu harus disimpan bersama datanya
  • Dalam bidang seperti keuangan, ketika jam buka pasar itu penting, UTC saja tidak memadai

• Di beberapa negara (Cuba, Egypt, Lebanon), perubahan DST terjadi pada tengah malam
  (tautan terkait)

  • Saya kaget mengetahui bahwa ada tempat di mana perubahan DST tidak terjadi selain tengah malam
    Di Brasil, perubahan pada 00:00~01:00 atau 00:00~23:00 dulu cukup umum
  • Aturan zona waktu benar-benar melakukan banyak hal yang sulit diprediksi

• Ada penelitian yang menunjukkan bahwa pada hari penyesuaian DST, angka kematian dan kunjungan ke IGD melonjak tajam
  (artikel ScienceAlert)
  Jadi ini bukan cuma masalah cron — DST adalah sistem yang juga berdampak buruk pada kesehatan

• Masalah ini sebenarnya sudah lama diselesaikan di OpenBSD dan Debian
  Di manual cron(8) Debian dijelaskan logika penanganan pergeseran waktu kurang dari 3 jam saat penyesuaian DST
  (tautan patch,
  manual,
  laporan bug)

  • Kalau begitu, sepertinya penulis artikel asli memakai distribusi yang belum menerapkan patch ini

• Ini adalah saran untuk tidak menjadwalkan pekerjaan pada tengah malam (00:00)
  Karena tanggal mudah membingungkan, lebih baik gunakan jam yang tanggung seperti 00:01 atau 01:45

  • Saya juga mengatur pekerjaan cron di XX:13, XX:23, XX:42 dan semacamnya
    Saat sistem bertingkah aneh pada waktu tertentu, jadi lebih mudah menelusuri penyebabnya
  • 00:00 hampir tidak pernah menjadi masalah
    Hanya saja, di lingkungan yang memakai jam 12 jam, kebingungan memang bisa muncul

• Sebelum mengalami masalah zona waktu, saya tidak sadar bahwa
  ada waktu yang tidak pernah ada dan waktu yang ambigu di dunia ini
  Misalnya saat meloncat dari pukul 2 ke 3, 2:30 tidak pernah ada,
  sedangkan saat jam dimundurkan, 2:30 muncul dua kali
  Karena tiap negara punya waktu penyesuaian DST yang berbeda, ada juga kasus seperti Chile yang kehilangan tengah malam
  (blog terkait)
  Saya ingat Java dan Ruby menangani situasi ini secara berbeda, dan pada masa awal bekerja di Stripe, hal itu menyebabkan tiga insiden berturut-turut

• Untuk pekerjaan cron, hindari tepat di pergantian jam, dan kalau bisa jadwalkan setelah pukul 4 pagi atau sebelum tengah malam
  Di infrastruktur bersama, persaingan sumber daya pada tepat pergantian jam biasanya tinggi

  • Opsi RandomizedDelaySec di systemd bisa dipakai untuk mengurangi bentrokan
  • Menambahkan kode seperti sleep $(( $(od -N1 -tuC -An /dev/urandom) % 60 ))m ; sebelum perintah cron
    untuk memberi penundaan acak 0–59 menit juga merupakan cara yang bagus

• Pekerjaan terjadwal yang penting sebaiknya dibuat idempotent (aman dijalankan berulang) bila memungkinkan
  Terutama ketika melibatkan sistem antrean, desain seperti ini adalah kunci pencegahan masalah