bracketed paste모드가 켜졌거나 켜진 상태에서 비정상적으로 종료했을 경우 이와 같은 증상이 나타날 수 있다. 해당 경우에는 \e[?2004l를 출력하면 빠져나와 정상적으로 붙여넣기를 수행할 수 있다. 반대로 켜고 싶은 경우에는 \e[?2004h를 출력해 진입할 수 있다.
해결사가 왔어!
php7.2로 업데이트 한 뒤 fpm이 재시작 시 실행되지 않음
WordPress health check이 최신 버전을 쓰는게 어떠냐는 식으로 물어보기에 업데이트를 했더니 재시작을 할 때 정상적으로 실행이 되지 않았다. 지난 몇번은 재시작이 되지 않으면 수동으로 시작을 했으나, 이번에는 그걸 까먹고 있다가 하루 종일 WordPress가 다운 상태(502)로 있었다. 어쩔 수 없이 이유를 확인하도록 한다.
VPS의 32비트 OS를 64비트로 교체할 생각을 하지 말자
32비트 OS image로 생성을 했다가, 나중에 이런 64비트로 교체하고 싶다.. 라고 생각을 해도 어떻게 할 수가 없다. VPS 사양 자체는 전원만 내리는 것으로 대부분 변경이 가능하나, 64비트로의 교체는 자동으로 이루어지지 않는다. 수동으로 가능은 하나, OS의 메이저 버전 업그레이드와 마찬가지로 클린 재설치 이후 이전하는 것이 문제를 덜 일으킨다. 우분투를 가장 많이 쓰는데, 데비안 32비트에서 64비트로 업그레이드 […]
윈도 셸 프롬프트 변경
Overview 윈도 기본 프롬프트는 복잡한 경로에 있을 때 보기 불편하기만 하다. 프롬프트로 출력되는 형태는 PROMPT로 저장되어 있다. echo %prompt%로 현재 값을 확인할 수 있다.
gdb – unhandled dyld version (15)
https://github.com/Homebrew/homebrew-core/issues/20047 위 글의 마지막 코멘트를 보자. 해결책은 둘 중 하나다. dyId 15를 요구하지 않는다. (다른 IDE를 사용한다.) gdb 8.1로 업그레이드 한다. 8.0.1의 소스 코드에서 define된 상수를 수정하는 것은 추천하지 않는다.
cron의 로그 위치와 설정
기본 설정 /var/log/syslog에 로깅되도록 되어있다. 변경 syslog는 rsyslog가 남기고 있다. 따라서 /etc/rsyslog.d의 conf에 설정을 남겨준다. 기본으로 50-default.conf에 쓰여 있는 #cron.*로 시작하는 행을 주석 해제 / 설정하는 것이 좋다.
init.d의 log는 없다.
rc.d에 있는 스크립트가 실행될 뿐이라 로그가 따로 남지 않는다. 해당 명령의 실행 결과는 STDOUT과 STDERR로 빠져나가므로, 스크립트가 실행하는 프로그램이 직접 남기는 로그를 확인해야 한다. (예 : nginx라면 nginx가 남기는 로그) rc.d의 스크립트를 직접 래핑하는 것은 추천하기 어렵다.