공부

서버 재부팅시 어떤 사용자로 로그인 되는지 와 상관없이

특정 사용자로 스크립트를 실행하고 싶었다

그러던 중 crontab에서 @reboot 라는 옵션을 사용하면 된다는 걸 알게 되었다.

로그는

/var/log/secure

/var/log/cron

위의 두 개의 파일을 참조 했다.

Feb 19 10:51:28 host01 crond[1207]: (test_user) FAILED to authorize user with PAM (Authentication token is no longer valid; new one required)

비밀번호 문제일 수 있어 확인하니 비밀번호가

만료라고 나옴

chage -l test_user

비밀번호 만료일자 비활성화 후 실행하니 PAM관련 에러메세지가 더 이상 나타나지 않음

sudo chage -M -1 test_user

0 30 * * 5 /home/test_user/test.sh

or

0 30 * * 5 cd /home/test_user && ./test.sh

젠킨스 에러가 갑자기 발생

어제 까지 잘되던 파이프라인이 갑자기 안됨

server connecting...이라고 메세지 이후에 나온것이기에 연결문제로 판단

이후 확인해보니 ssh 접속 시 사용되는 계정의 비밀번호가 만료됨 비밀번호 갱신하여 해결

chage -l 계정


Last password change					: Aug 19, 2023
Password expires					: never
Password inactive					: never
Account expires						: never
Minimum number of days between password change		: 90
Maximum number of days between password change		: 99999
Number of days of warning before password expires	: 30

 위 명령어로 검색한 계정은 만료가 되지 않음을 확인했다.

말 그대로다.

DB LOCK에 관하여 슬랙 알람을 보내야 한다.

기존에 jsp로 알람을 보내는 사이트가 있고, LOCK 관련 정보를 불러오는 쿼리는 구현되어 있다.

이것을 이용하여 고대로 jsp에서 쉘 스크립트를 실행하여 슬랙으로 알람을 받을 수 있게 해야한다.

우선 jsp 파일 상단에 저것들을 import 해준다.

사용할 변수들을 중간에 선언 해주고

sql 쿼리도 실행 해준다.

쿼리 결과는 rs1에 컬럼이름과 해당 데이터가 키 -값의 쌍으로 매핑 되어 있다고 한다.

락 발생 이후 경과 시간에 따라 다른 동작으로 구분 하였으며 60초에서 70초 사이에 슬랙 알람을 보내도록 하였다.

60초에서 70초 사이로 한 이유는 윂페이지가 리프레쉬 하는 간격이 가끔 안맞으면 61초에 리프레쉬 되어 알람이 울리지 않기 때문에 시간 간격을 10초로 하였다.

그러면 문제가 발생하는데 10초 동안 계속해서 스크립트가 실행된다.

그래서 스크립트에서 락을 걸어 한 번만 10초 동안 동작하게 하여 60초 70초 사이에 한 번만 동작하게 한다.

:ㅂ

매개변수를 받아와서 슬랙에 알람을 보내고 10초 동안 일시정지 하여 10초 안에 한 번만 동작하게 한다.

파일에 락을 걸어서 한 번만 스크립트가 실행되게 하는 방식이다.

exec 200>$LOCK_FILE
flock -n 200 || exit 1

파일 디스크립터 200을 LOCK_FILE에 할당한다.

(파일이 없는 경우 생성, 혹시 몰라 touch로도 파일 생성 하도록 작성)

flock으로 200 디스크립터가 할당된 파일에 락을 걸어주고

-n 옵션으로 다른 프로세스에서 200 디스크립터로 접근 하면 락을 얻지 못하게한다.

락을 얻은 후 스크립트가 이어서 실행되며 슬랙 알람 전송 후 sleep 10으로 10초동안 일시정지 시켜

10초 동안 한 번만 실행되도록 한다.

이후 flock -u 200으로 200 디스크립터에 적용된 lock을 해제하고

락 파일 삭제

sonarqube를 컨테이너로 옮기면서 sysctl 문제가 다시 발생했다.

vm_max_map_count 값이 65530 으로 너무 낮았다.

그래서 원래 sysctl 에서 262144 로 바꿔주었는데

Dockerfile에서 "RUN sysctl ~" 이런식으로는 바뀌지 않았다.

그래서 찾아보니 Dockerfile에서 저 명령어를 사용하면 이미지를 빌드하는 호스트의 vm_max_map_count 값이 바뀐다고 한다.

그 이미지를 사용하는 컨테이너에 적용되는 vm_max_map_count가 바뀌는게 아니다

그래서 찾아보던 중 크게 2가지 방법이 있었다.

1. 노드의 sysctl 값을 변경

2. init container에서 "sysctl ~~" 명령어를 실행

노드에서 sysctl의 값들을 변경하면 해당 노드에 생성되는 파드, 컨테이너들에 모두 적용된다.

그러나, init container를 이용해 sysctl을 사용하면 init container가 있는 pod의 vm.max_map_count가 변경되고

같은 pod에 있는 다른 컨테이너들은 변경된 vm.max_map_count가 적용된다.