'개발/Linux, System'에 해당되는 글 57건

daemonize 옵션을 지원하지 않는 foreground 프로세스의 경우 background 형태로 동작하는 것처럼 하려면 보통은 nohup 명령어를 사용하여 아래와 같이 실행을 하게 된다.

$ nohup program &

실행을 하고나면, 명령어를 실행한 경로에 nohup.out이라는 파일이 생기며, program 이라는 프로세스가 뿜어내는 로그들을 찍게 되는데, 이후에 해당 프로세스를 죽이거나 재실행 하기 위해서는, 프로세스를 일일히 뒤져서 pid를 알아내서 죽여야 한다.

이런 번거로움을 방지하기 위해서는, nohup 명령어로 프로세스를 띄울 때 pid를 파일로 저장해서 해당 파일이 존재하는 경우 kill을 하고 띄우는 방법을 이용하면 좋을 것 같아서, 아래와 같은 스크립트를 하나 만들어서 활용하기로 하였다.

#!/bin/bash

if [ -f program.pid ]; then
  kill -9 `cat program.pid`
fi

nohup program > nohup.out 2>&1 & echo $! > program.pid

nohup.out 파일조차 남는게 지저분해보이고 귀찮으면, nohup.out 부분을 /dev/null로 변경해주면 된다.

adb shell am start -n {패키지명}/{메인 액티비티명}

사용하던 매크로에서 기능 패치가 안되서 찾아봤는데 이 쪽도 재미있어보인다.

윈도우 환경에서 Batch를 짜서 작업 스케줄러에 등록하면, 기본적으로 명령프롬프트 윈도우가 하나 뜨기 때문에, 실제 사용하고 있는 컴퓨터에서 돌아가고 있다면 거슬릴 것이고, 서버라고 하더라도 보기가 안좋다.

이런 경우에는 VB Script를 이용해서 Batch 스크립트를 실행하면 깔끔하다.

아래와 같이 작성하고, 파일명.vbs 로 저장해서 실행하면 됨.

Set WinScriptHost = CreateObject( "WScript.shell" )
WinScriptHost.Run Chr(34) & "C:\실행할배치파일.bat" & Chr(34), 0
Set WinScriptHost = Nothing

사내에 Zabbix를 구축해서 사용하고 있지만, 이게 active 방식인지 passive방식인지 파악을 안하고 있었고, 설정 파일 및 템플릿을 최초에 구성한 사람이 이미 존재하지 않기에(...) 방화벽을 양방향으로 열어서 사용을 하고 있었다.

최근에 방화벽 정책을 누군가 정리하면서, agent가 server에 데이터를 전송하는 방식인지, server가 agent에 데이터를 달라고하는 방식인지 확인해보게 되었다.

당연하겠지만, 공식홈의 document에 가장 정확하게 설명되어 있다.

(https://www.zabbix.com/documentation/2.2/manual/appendix/items/activepassive) 

• Active 방식
• 사전조건으로 agent 설정 파일에서 serverActive의 ip를 지정해주어야 그 ip를 참조해서 데이터를 전송할 수 있다.
• Agent -> Server로 데이터를 전송하는 방식 (TCP 10051 포트를 이용)
• Item 구성 시 Zabbix Agent (active)를 선택하면 Active 방식으로 사용 가능

• Passive 방식 (Default)
• 별다른 설정 없이 기본 동작 방식임.
• Server -> Agent로 데이터를 수집하는 방식 (TCP 10050 포트를 이용)
• Item 구성 시 Zabbix Agent 를 선택하여 구성

정리해보자면, Zabbix에 구성된 Item을 우선적으로 확인하고, Agent의 설정 파일을 점검해보아야, 해당 서버가 Active방식인지 Passive방식인지 알 수 있으며, ACL 등 방화벽 정책 처리를 할 때도 어떤 방식으로 동작하느냐에 따라 달라질 수 있다.

Ubuntu 16.04 환경에서 systemctl 기반의 서비스 관리를 하면, /var/run/ 이하의 폴더들을 reboot 시 마다 날리고 새롭게 구성하는 것을 확인하였다.

그래서 대부분 systemctl으로 등록할 수 있는 서비스 들에는 최종적으로 동작하는 스크립트 전에 /var/run/ 이하의 폴더가 있는지 체크를 하여 생성해주는 로직이 들어있는데, zabbix-agent의 경우 지금 사용하는 버전이 2.x 대이기 때문에 그런 고려따윈 없었다.

그래서 아래와 같이 폴더를 체크하여, 생성해주는 구문을 넣으니 정상동작하였다.

...
DIR=/var/run/zabbix

if test ! -d "$DIR"; then
        mkdir "$DIR"
        chown -R zabbix:zabbix "$DIR"
fi
...

구 버전을 사용하다보니 예상치 못한 문제들이 많이 발생하는듯

zabbix-agent 설치 간, 14.04 기준의 init.d 스크립트를 16.04에 systemctl 명령어로 추가를 하려했더니, 아래와 같이 경고가 발생하였다.

$ systemctl enable zabbix-agent
insserv: warning: script 'zabbix-agent' missing LSB tags and overrides

systemctl를 이용하여 서비스를 등록할때는 LSB 태그가 필요하다는 경고였고, 저게 말은 Warning이지만 제대로 등록이 되질 않았다.

그렇기 때문에, LSB 태그를 아래와 같이 추가를 해주니, 정상적으로 등록이 되는 것을 확인하였다.

#
# Zabbix agent start/stop script.
#
# Copyright (C) 2000-2012 Zabbix SIA
### BEGIN INIT INFO
# Provides:          zabbix-agent
# Required-Start:    $remote_fs $network 
# Required-Stop:     $remote_fs
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: Start zabbix-agent daemon
...
### END INIT INFO

컴파일해서 설치한 Apache2 (정확한 버전은 2.2.17)이 설치되어 있는, 머신의 OS를 Ubuntu 12.04에서 14.04로 업그레이드 할 일이 생겨서 OS에서 제공하는 커맨드로 OS 업그레이드 후에는 문제가 없었지만, 재부팅 이후에 httpd 데몬을 띄우려고 하면, 아래와 같은 에러 메시지가 발생하였다.

[emerg] (22)Invalid argument: Couldn't set permissions on cross-process lock; check User and Group directives

12.04에서는 아래와 같이 유저 / 그룹이 설정 되어 있었는데 잘 동작을 했었지만, 14.04에서는 계정정책이 뭔가 바뀐 듯 하다.

# httpd.conf
...
User nobody
Group #-1
...

정확한 원인은 모르겠지만, nobody라는 계정이 httpd 데몬을 띄우는데 뭔가 권한이 부족한 것으로 판단하여, 새로운 그룹과 유저를 생성 한 후, User와 Group을 변경하니 해결되었다.

하나의 서버가 http와 ws스펙을 지원해야 하고, apache / nginx 같은 웹서버 뒷단(Proxy 환경)에서 서비스를 해야 되는 경우가 생겼다.

nginx같은 경우 간단하게 헤더 몇개만 추가해주면 자연스럽게 해결이 되는데,

apache같은 경우는 rewrite engine과 proxy_wstunnel engine을 enable 시킨 후, 별도의 조건까지 등록을 해주어야 가능하다.

아래 커맨드는 Ubuntu / Debian 계열 Linux 기준의 예제이고, 위에 얘기한 engine들을 enable 시키는 방법은 아래와 같다. 

$ a2enmod rewrite        # 보통 default로 enable 되어있는 경우가 많다.
$ a2enmod proxy_wstunnel

이제 Rewrite Engine 설정을 해준다. (포트가 6050인 경우)

# http-vhosts.conf
RewriteEngine on
RewriteCond %{HTTP:UPGRADE} =websocket [NC]
RewriteRule .* ws://127.0.0.1:6050/$1 [P,L]

ProxyPass / http://127.0.0.1:6050
ProxyPassReverse / http://127.0.0.1:6050

모든 작업 후 apache2를 재시작 해주면 적용된다.

정리하는 김에.. Nginx같은 경우는 아래와 같이 설정하면 됨.

server:
  location /:
    proxy_pass http://127.0.0.1:6050;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_set_header Host $host;

SSH 서버 하나에 붙어서, 여러가지 명령을 처리해야 하는 경우 application 단에서는 SSH 서버에 인증을 한 후 RPC콜을 위해 요청 하나마다 세션을 하나씩 할당받아서 사용하게 되는데, Linux 머신의 sshd의 경우 MaxSession값이 Default값이 10으로 되어 있어서, 10개 이상 요청하려고하면 연결이 안된 것처럼 오동작을 할 때가 있다.

이런 경우 sshd_config 설정을 조금 건드려주면, 원활하게 처리가 가능하다.

아래 키워드를 sshd_config 설정 안에 포함을 시키면, 원하는 개수만큼 세션이 늘어나게 된다.

MaxSessions 200

위 내용을 추가하고, 서비스를 재시작 해주면 완료

$ service sshd restart       # 서비스 재시작 (환경에 따라 서비스명이 ssh일수도 있음)
$ /usr/sbin/sshd -T | grep -i maxsessions      # 적용된 내용 확인

vm환경에서 CentOS를 사용하다가, 특정 프로세스가 메모리점유를 많이해버려서, 메모리가 부족하게 되면,

커널 설정에 따라, oom-killer가 동작을 하고, 원하지 않는 서비스가 제멋대로 kill되어 버리는 상황이 발생한다.

메모리가 부족해도 서비스가 돌아가야 하는 상황에서는, vm.overcommit_memory 값을 변경하여

프로세스가 kill되지 않도록 할 수 있다.

vm.overcommit_memory값은 0~2까지 설정할 수 있으며, 값에 대한 정의는 아래와 같다.

- 0 : 메모리 부족 시 프로세스를 kill

- 1 : 항상 overcommit 허용 (kill하지 않음)

- 2: vm.overcommit_ratio에 설정된 범위만큼만 overcommit을 허용)

여기서는 항상 overcommit을 허용하도록 세팅을 해보도록 하겠다.

$ sysctl vm.overcommit_memory = 1     # 커널 설정 변경
$ echo "vm.overcommit_memory=1" >> /etc/sysctl.conf  # 재부팅 시에도 유지할 수 있도록 파일에 추가
$ sysctl -a | grep overcommit_memory   # 확인