init systemd 차이 매우 자세히!

안녕하세요 마무입니다. 오늘은 '리눅스 최초의 프로세스', 'init systemd',  "centos 6.9이하와 7이상 차이"와 "init systemd 비교"에 대해서 알아보겠습니다.


/***이 포스트를 이해하기 위해 반드시 알고 있어야하는 사전 지식***/

데몬과 서비스, 프로세스란: https://mamu2830.blogspot.com/2020/04/blog-post_18.html

리눅스 부팅 과정: https://mamu2830.blogspot.com/2020/08/swapper.html

시스템 콜이란: https://mamu2830.blogspot.com/2021/01/whatIsSystemCall.html

/****************************************************************************/


-----목차-----

1. 리눅스 최초의 프로세스와 부모 프로세스, 자식 프로세스란

2.  init과 systemd이란

i) 프로그래밍에서 init이란

3. 리눅스 최초의 프로세스를 공부해야하는 이유
i) init과 systemd 둘다 공부해야하는 이유

4. init systemd 차이

i) systemd init 비교

---------------

여기서 못 찾은 정보는
리눅스 독학 페이지 : https://mamu2830.blogspot.com/p/blog-page_13.html
운영체제 독학 페이지 : https://mamu2830.blogspot.com/p/blog-page_14.html
에서 찾아보시면 있을 수 있습니다!

---

1. 리눅스 최초의 프로세스와 부모 프로세스, 자식 프로세스란

https://mamu2830.blogspot.com/2020/08/swapper.html 포스트의 'i)리눅스의 부팅과정' 에 써 있는대로 정상적으로 부팅이 진행되면, 결과적으로 커널(운영체제)는 'init(systemd)'이란 이름의 '최초의 프로세스'를 실행합니다. 

그리고 '최초의 프로세스'라는 이름대로 'PID(Process ID)'는 '1번'을 배정받습니다.

'PID'는 다른 포스트에서 프로세스 명령어들과 함께 자세하게 다룰 예정이므로, 여기선 그냥 말 그대로 'Process(프로세스)들을 구분하기 위한 ID(겹치지 않는 식별자)'라고 생각해주세요. 

그리고 '리눅스'에서는 이 '최초의 프로세스'를 fork()라는 시스템콜을 이용해 복사해, 리눅스 부팅 때 필요한 모든 프로세스들을 만듭니다.

위 사진은 Centos 6.9이하 버전에서 'pstree(process tree)'란 명령어를 쳤을 때 나오는 결과로, 주황색 동그라미를 보시면 정말 6.9 이하에선 'init'이란 프로세스로 시작해서 다른 모든 프로세스가 시작되는 것을 볼 수 있습니다.

정말 '나무(tree)'란 이름이 들어가는 'pstree' 명령어대로 프로세스 족보를 나무처럼 보여주는 것이죠.

네? 이게 어디봐서 나무라고요? 

흐음~ 그럼 이러면 어떨까요?

이렇게 말이죠!

네? 이게 어딜봐서 나무냐고요? 어... 그럼 한번 더 이해하기 쉽게 그림으로

바꿔보겠습니다.

위 90도 회전시킨 사진을 좀 더 이해하기 쉽게 만들어 봤습니다.

맨 처음 시작되는 'init(최초의 프로세스)'은 마치 나무의 시작인 줄기와 같고, '다른 프로세스들'은 그 줄기로부터 시작되는 가지들인 것이죠. 

                                        

이제는  확실히 나무같죠? 

자 'pstree'가 나무처럼 구조를 보여주는 명령어라는 것을 알았으니, 다시 돌아와 이 사진을 왼쪽에 있는 프로세스와 오른쪽에 있는 프로세스의 차이에 대해서 말해보겠습니다.

여기선 'init'이 맨 왼쪽에 있죠? 이 때 오른쪽에 'init'과 바로 연결돼 있는 프로세스 (NetworkManager, abrtd, acpid, anacron, atd........)들은 모두 fork()라는 시스템콜을 이용해 최초의 프로세스 'init'을 복사해서 만들어졌다는 뜻입니다. 

말 그대로 이 때 왼쪽에 있는 'init'으로부터 새로운 생명(프로세스)이 만들어진 것이니, 'init'은 오른쪽 프로세스들의 '부모' 라고 해서, 부모 프로세스라 이름을 붙인 것이죠. 

참고로 우리나라에서만 이렇게 부르는 것이 아니라, 실제로 영어로도 parent(부모) process라고 합니다.

그리고 같은 맥락으로 왼쪽에 있는 부모 프로세스를 복사해서 만들어진 오른쪽에 있는 프로세스를 부모로부터 만들어졌다 해서 '자식 프로세스'라고 하는 겁니다.

또한 'pstree' 명령어를 볼 때, 부모와 자식 프로세스의 관계를 나무에 비유했었잖습니까?

비유뿐만 아니라, 실제로 프로세스들의 구성과 메커니즘도 나무와 똑같기 때문에 줄기(init)로부터 이어진 가지(부모프로세스)가 끊어지면(종료되면) 그 가지에 이어진 다른 가지들(자식프로세스들)도 죽습니다.(물론 정확히 따지자면 최초의 프로세스인 'init'이 부모 역할을 하기도 합니다)

어! 그러면 같은 원리로 당연히 모든 프로세스의 부모이자 줄기인 최초 프로세스(init 또는 systemd)를 종료하면, 모든 프로세스가 종료되니 즉 시스템이 꺼지나요!?

음... 이론은 그렇지만 당연히 그런식으로 시스템을 종료하면 심각한 문제(커널 패닉)가 생기므로 당연히 리눅스를 설계할 때 못하게 막아놨습니다. 

그래서 나중에 배울 'kill -9'와 같은 '프로세스 강제종료 명령어(시그널)'를 사용해도 'init(systemd)'프로세스는 강제 종료할 수 없습니다.(물론 특정 시그널을 통해서는 가능하다는 말이 있지만 심각한 문제가 초래될 수 있으니 안 알려줄겁니다ㅎㅎ..)

아 물론 지금까지 말한 부모 프로세스를 복사해 자식 프로세스를 만드는 'fork()' 방식과 '최초의 프로세스', '부모, 자식 프로세스' 등의 개념은 'init'만 해당되는게 아니라, 'systemd'에서도 똑같습니다. 

CentOS 7버전 이상(systemd 사용하는)에서 똑같이 'pstree'라는 명령어를 통해서 확인해보시면

이렇게 나옵니다. 위 사진의 주황색 부분을 보시면 'init 프로세스'를 쓰는 시스템과 똑같이 'systemd'란 녀석이 맨 처음 실행되는 최초의 프로세스이자, 다른 프로세스들의 부모 프로세스가 되는 것을 볼 수 있습니다~

이렇듯 대부분의 유명한 리눅스 계열들을 '최초의 프로세스'를  'init' 프로세스를 쓰느냐 'systemd' 프로세스를 쓰느냐로 크게 나뉩니다.

자 여기까지 최초의 프로세스라는 'init', 'systemd'라는 것의 존재와, 그 역할, 부모, 자식 프로세스에 대해서 알아봤습니다. 

그럼 이번에는 'init', systemd'란 녀석들이 도대체 뭔지, 이름이 왜 저따구인지 등등 좀 더 자세한 정보와 차이에 대해서 알아보도록 하겠습니다!

---

2.  init과 systemd란

'init'은 "initialization(초기화, 시작하기 위한 세팅)"의 약자로, 6.9이하 버전에서 "리눅스의 정상적인 부팅을 위해 초기화를 해주는 프로세스"라는 역할을 하는 최초의 프로세스이기에 이렇게 이름을 지었고

'systemd'은 "system management daemon"의 약자로 말 그대로 "기존 init 기능 + 시스템을 총 관리해주는 데몬"이라서 그렇게 이름을 지어주었다 생각하시면 됩니다.

그리고 당연히 'init, systemd' 둘 다 최초의 프로세스로서 핵심적으로 하는 역할(모든 프로세스의 부모, 프로세스 관리, 부팅에 관여 등등)은 비슷하기에 대부분의 리눅스 계열은 'init' 또는 'systemd' 중 하나만을 씁니다. 

그럼 'init'과 'systemd'는 취향차이인가? 라고 생각이 드실 수 있는데.. 

음... 취향 차이라고도 볼 수는 있지만... 그것보단 'init'은 '과거부터 사용해오던 시스템'이고, 'systemd'는 '최신 시스템'이라고 보시는게 더 좋을 것 같습니다.

왜냐면 위에서 말했다시피, 'systemd' 는 기존 'init' 프로세스의 역할뿐만 아니라 시스템 전체를 총 관리할 수 있는 다른 기능들도 추가된 데몬이기 때문이죠.

물론 여러가지 기능을 다 할 수 있는 'systemd'는 기존 유닉스계열 시스템의 철학 '한 가지만 잘하자' 라는 취지를 벗어났기에, 싫어하는 사람들도 있어서 취향을 타긴합니다만~~ 역시 'systemd'가 기존 'init' 프로세스보다 압도적으로 성능이 향상, 기능이 추가 됐고, 최신 리눅스 버전들도 다 도입하고 있기에 이제는 'systemd'가 최신 시스템이라고 보셔도 될 것 같습니다.

그리고 앞에서 살짝 언급을 하긴 했지만 저희가 사용하는 'RedHat 계열(RedHat Enterprise, CentOS)' 리눅스는 6.9이하 버전에선 최초의 프로세스를 'init'란 것을 사용하고, 7이상 버전부터는 'systemd'이란 것을 사용한다고 아시면 됩니다.

물론 기존 init시스템을 사용하던 사람들을 위해, 'systemd'에서 'init'을 사용할 수도 있습니다.

사실 2020년도 까지만 해도, 리눅스마스터 시험은 'init'프로세스를 사용하는 centos 6.9이하를 시험으로 봤는데, 올해부터 'systemd'를 사용하는 7이상 버전을 시험으로 보게 됐죠.

i) 프로그래밍에서 init이란

좀 TMI(Too Much Information)일 수 있지만, 사실 원래 'init'이란 이름은 리눅스 최초의 프로세스뿐만 아니라, 다른 모든 프로그래밍에서 'init(initialization, 초기화)'라는 이름대로 초기화 과정에 자주 쓰이는 이름입니다.

그래서 그냥 프로그래밍에서 'init'이란 용어가 보이면, 프로그램을 정상적으로 실행하기 위해, 처음에 실행되는 과정(초기화 과정)이나 그런 역할의 함수라고 생각하시면 됩니다.

같은 맥락으로 리눅스에서의 'init'이란 단어는 '최초의 프로세스'인 동시에 리눅스 운영체제를 정상적으로 실행하기 위한 '초기화 과정'을 나타내는 단어이기 때문에 사실 'systemd'를 쓰는 리눅스 시스템이라고 해도, 초기화 과정을 나타낼 때 'init'이란 단어를 사용합니다.

그러니 나중에 man 페이지나 다른 커뮤니티에서, 'systemd'를 사용하는 시스템인데 'init'이란 단어를 사용한다고 해서 당황하지 않으셔도 됩니다! 

또한 만약 리눅스의 프로세스 'init'에 대해서 궁금한 것이 있으면, 위에서 말했듯이 그냥 'init'이란 용어는 다른 프로그래밍에서 자주 쓰이기에, 리눅스 외 다른 정보들도 다 나옵니다. 

그럴 때 'sysVinit'이라 치면 우리가 원하는 '리눅스 init'에 대한 정보만 나옵니다. 왜냐면 지금까지 말한 'init'프로세스는 옛 유닉스 'sysV'에서 지금까지 사용해오던 프로그램이기 때문입니다~(sysV 등등 리눅스 역사가 궁금하시면, 리눅스 역사 총 정리 포스트를 보고 오세요!)

쉽게 "linux init process == sysVinit"이라 생각하시면 됩니다.

---

3. 리눅스 최초의 프로세스를 공부해야하는 이유

자 여기까지 읽으셨으면, "init은 구기술, systemd가 신기술, systemd가 더 좋음" 까진 이해가 되셨을 겁니다만 이런 의문이 들 수 있습니다.

왜 굳이  '최초의 프로세스'라는 것을 상세히 알아야하지? 그냥 그런게 있다 정도로만 알고 넘어가면 안되나?

라고 말이죠..

음... 맞습니다. 사실 리눅스를 잘 사용할 줄 아느냐의 수준인 '리눅스마스터 2급'까지만 공부하실 생각이라면, 더 자세하게 안 배우고, 그냥 "최신 리눅스는 systemd를 씀, systemd는 init + 시스템 전체를 관리할 수 있는 기능"까지만 알고 넘어가도 상관은 없습니다(물론 프로세스 관련 명령어는 알아야하겠죠?)

하지만 여러분이 서버를 관리할 수 있느냐라는 '리눅스마스터 1급'까지 공부하실 생각이라면, '최초의 프로세스'의 원리와 관련 디렉토리에 대해서 잘 알아야합니다.

왜냐면 실시간으로 서버 프로세스를 관리할 수 있어야 하고, 프로세스의 특징과 생성 원리, 또 데몬(서비스)를 만들고 관리할 줄 알아야하는데 이 때 당연히 '최초의 프로세스 init(systemd)'가 관련되기 때문입니다.

그리고 이런 프로세스 관련 기술, 지식들은 서버 관리에 필수적이며 원래 '총'을 아군이 들고 있으면 보안용이지만, 적군이 들면 무기가 되듯이, 서버 관리, 보안 기술은 살짝 뒤집으면 바로 해킹 기술이 되기 때문에 보안 공부를 하시는 분들도 당연히 잘 알아야하죠.

i) init과 systemd 둘 다 공부해야하는 이유 

그럼 'systemd'가 더 좋고, 최신버전에 'systemd'가 쓰이는 추세니, 'systemd'만 공부하면 되는거 아닌가요?" 란 의문이 드실겁니다. 

물론 시험을 목적으로 하신다면 그렇게만 하셔도 됩니다만, 실용성을 목적으로 하신다면 결국 둘 다 공부를 하셔야 할겁니다...

그 이유는 리눅스 독학 포스트 첫 번째인 "리눅스 설치편"에서 제가 "리눅스는 서버에서 많이 쓰이는 운영체제다"라고 말을 했었는데 기억이 나시나요? 그리고 그 이유중 하나는 바로 "안전성"에 있다고 말이죠.

같은 맥락으로 서버의 입장에선 무엇보다도 가장 중요한건 바로 "안전성"입니다. 그렇기 때문에 보통 서버들은 게임마냥 새로운 버전이 나왔다고 운영체제 업데이트를 확확 하지 않습니다.  상당히 보수적이죠...

그런데 그럴 수 밖에 없는게, 개인 PC에 비교해서 서버들은 정~~말 많은 컴퓨터와 장비들이 서로 연결이 돼 있고 요즘 서버는 대부분 서버 가상화 기술(수~~~~많은 컴퓨터들을 가상화 기술들을 이용해 하나로 합치는 것)과  클라우드 환경(인터넷을 통해 서버를 이용하는 것)을 이용해 만들기 때문에, "가상 서버를 이루고 있는 컴퓨터들끼리의 상호관계"와 또 "클라우드 프로그램과의 호환성", "지금까지 사용해오던 다른 모든 서버 프로그램들과의 호환성", 그리고 "운영체제 버그 문제" 등등을 고려해봤을 때, 정말 서버입장에선 운영체제를 업그레이드할 경우 감수해야할 위험 부담이 너~~무나 크기 때문이죠.

이렇듯 서버에선 안전성이 제일 중요하기 때문에, 기존에 "6.9이하 시스템(init)"을 써오던 서버들은 "7이상 버전(systemd)"으로 업그레이드 하지 않고 계속 사용하는 경우가 많습니다.

그렇기 때문에 아직까지도 서버에서 버전은 '6.9버전 이하'가 약 절반 정도 사용되며 요즘들어 겨우 7.0이상은 절반도 안되게 사용되기 시작했다고 합니다.

그래서 지금까지 리눅스마스터 시험을 6.9이하 버전으로 했던 것이죠. 하지만 systemd를 사용하는 시스템의 장점이 앞서 설명한 부팅 속도 뿐만 아니라 훨씬 많으며, 앞으로 나오는 7.0이상 버전은 모두 systemd를 사용하고 점점 그 수도 증가할 것으로 보이니 결국 저희는 저흰 {init, systemd}시스템 공부를 둘 다 해둬야하는 겁니다. 

---

4. init systemd 차이

자 그럼 한번 본격적으로 자세하게 'init'과 'systemd'의 차이에 대해서 비교해보겠습니다.

일단 가장 체감이 되는 큰 차이는 바로 부팅 때 다른 프로세스들을 병렬적으로 키는가 아닌가라 볼 수 있습니다.

"갑자기 병렬적이라니... 무슨 소리인가요?"

무슨 소리냐면, 'init 프로세스'는 부팅 때 '모든 서비스(데몬)'을 순서대로 차례차례킵니다. 

차례차례라는 건 앞에 프로세스가 완전히 실행돼야, 그 다음 순서 프로세스를 실행시키는 방식이라는거죠. 그냥 쉽게 프로세스들이 실행되기 위해 한 줄로 서 있다고 보시면 됩니다

한 줄로 서 있다... 그것은 즉 '직렬'이라는 것을 의미하죠!

그래서 이런 'init'프로세스의 방식을 한 단어로 표현하자면 '직렬'방식이라고 하는 것입니다. 

그리고 '직렬 방식'의 단점은 바로 앞 순서의 시스템에 필수적인 특정 프로세스가 켜지는게 오래걸리면, 뒷 순서의 나머지 프로세스들은 대기해야하기 때문에 부팅이 오래걸릴 수 있다는 것입니다.

예를 들자면 사람들(프로세스들)이 버스를 타려고(시작되려고) 줄을 서 있는데, 버스 입구에서 누군가(특정 프로세스)가 결제가 오래걸리면, 그만큼 뒤에 기다리는 사람들은 버스에 못 들어가는(시작 못하는) 것과 마찬가지인 겁니다. 

그리고 당연히 모든 손님이 버스에 탑승하지 못했기에 버스(시스템)는 출발하지(부팅 되지) 않습니다.

 

나중에 'init'을 전문적으로 다룬 포스트에서 나올 내용이지만, 위 사진처럼 6.9이하 버전에서 "/etc/rc.d/rc3.d/"란 디렉토리를 보시면 K01, K02, S10 등등 파일 이름 앞에 숫자가 써 있는 파일들이 보이실텐데요, 이 숫자들의 의미는 'init'이 이 숫자 순서대로 프로세스를 시작한다는 의미입니다.(더 자세한건 'init'포스트에서 다루겠습니다)

그렇기에 만약 'S10network'란 프로세스가 완전히 켜지는데 오래 걸리면, 그만큼 뒷 순서의 S11, S12, ....들은 켜지는데 오래 걸리는 겁니다.

이처럼 'init'은 직렬적인 방식이라 부팅이 오래걸릴 수 있다는 단점이 있습니다.

그래서 이런 '직렬'방식의 단점과 기존 'init' 프로세스 시스템의 아쉬움 점들을 보완하기 위해 '레드햇 7이상' 버전부터 새로 도입한 시스템이 바로 'systemd'를 사용하는 시스템인 것입니다.

나중에 'systemd'만 다룬 포스트에서 설명할 것이지만, 'systemd'는 사실 'init'프로세스와는 다르게 시스템 초기화에만 관여하는 프로그램 뿐만 아니라, 시스템 전반적 관리에 쓰이는 다른 데몬들을 포함한(journald, logind, networkd 등등..) 종합세트의 이름입니다.   

어쨌든, 직렬 방식의 단점을 보완했다는 말에서 알 수 있듯이, 'systemd'는 'init'과 다르게 부팅에 필요한 프로세스들만 먼저 '병렬적'으로 시작합니다. 그렇기에 부팅할 때 특정 프로세스가 오래걸릴 경우, 기다릴 필요가 없으니 부팅시간이 init과 비교해서 훨씬 빠릅니다.

직렬 방식(init) 시스템은, 버스 앞문을 이용해서만 모든 손님이 버스에 탄 뒤 출발하는 방식이라고 치면 

병렬 방식(systemd)은 버스 앞문 뿐만 아니라 뒷문도 열어서 일단 손님들이 우르르 버스에 올라탄 다음, 각자 결제를 하되, 특정 인원 수 이상(부팅에 꼭 필요한 서비스들)이 결제(시작)를 완료하면 그냥 출발(부팅)하는 것입니다.

손님이 앞, 뒷문을 이용해 일단 버스에 탄 뒤에 각자 결제를 하고, 특정 수만 결제를 완료하면 출발하니,  좁은 앞문만 이용하며, 모든 인원이 결제를 마쳐야 출발 하는 직렬 방식보단 훨씬 빠르겠죠?

위 사진은 7이상 버전에서 6.9이하에서 init이 사용하던 "/etc/rc.d/rc3.d/" 디렉토리 내부를 찍은 사진인데요, 숫자들이 적힌 파일들이 있던 init시스템(6.9이하)와는 다르게 아무것도 없이 텅~ 비어있는 걸 볼 수 있습니다.

당연히 'init'에서 'systemd'으로 바뀌며, 사용하는 디렉토리가 완전히 바뀐 것도 있고, 서비스를 키는 방식이 완전히 달라진 것도 있습니다.

지금은 이해가 안 되실 수 있지만 미리 살짝 말하자면, 기존 'init'은 런레벨에 맞는 특정 디렉토리에 실행할 데몬들을 집어넣어 넣어놓고, 'init'이 특정 디렉토리를 선택 후 그 내부의 프로그램들을 순서대로 실행하는 방식이였다면

'systemd'는 어떤 데몬을 실행할지, 또 그 데몬은 다른 어떤 프로그램과 의존성을 갖는지 등등을 적은 ".target"이란 확장자가 붙은 설정파일들을 이용하여 런레벨과 데몬들을 실행하듯이 방식이 완전히 달라졌다는 것이죠.

그 외에 다른 세부적인 차이점들을 모두 이 포스트에 설명하자면 끝이 없으므로... 일단 'init'에서 'systemd'로 변하면서 생긴 큰 'systemd'의 특징들만 적어보겠습니다.

i) systemd init 비교

1) 프로세스의 관리에 있어서 더욱 효율적이고, 깔끔하며, 상태 지향적으로 바뀌었다.

 ex)데몬이 active 인지,  inactive인지 등등 상태를 잘 나타냄

상태 지향적으로 바뀌었다는 말은 글로만 이해가 잘 안되니 사진으로 보여드리자면

기존 init에서 실행중인 데몬의 상태를 보는 명령어를 치면

이렇게 되게 담백하게 그저 실행중이라고만 뜹니다. 

하지만! 'systemd'에서는?

이렇게 프로그램의 상세한 정보들과, 위 주황색 밑줄을 보시면 "active(활성 상태)"라고 써 있죠? 이런 활성 상태 이외에도 "active, inactive, failed"등등, 데몬의 '상태'를 나타내주기 때문에 더욱 효율적이고, 깔끔하며, 상태 지향적으로 바뀌었다고 하는 겁니다.

2) 부팅 때 프로세스 병렬처리를 통한 빠른 부팅

이건 위에서 설명했듯이, 병렬처리를 통해 더욱 빠르게 부팅한다는 것인데요, 그래도 그냥 넘어가면 찝찝하실테니.. 부팅 때의 systemd의 병렬처리 과정 사진을 보여드리겠습니다.

(출처 : https://man7.org/linux/man-pages/man7/bootup.7.html)

 더 자세한 정보들은 'systemd' 포스트에서 집중적으로 다루도록 하겠습니다.

3) 더 좋아진 API

4) 다양해진 단위(unit)(여기서 단위란, init이나 systemd가 인식하고 사용하는 파일을 말합니다.)

사실 단위가 다양해졌다? 말로만 들으면 이해가 안됩니다. 그래서 sshd 데몬을 예시를 들어 설명해보겠습니다. 

'init'시스템에서는 서비스(데몬)는 모두 다 그냥 서비스일뿐이고, 이름도 그냥 서비스 자체의 이름 그대로 'sshd'입니다. 

이렇게 주황색으로 표시한 것처럼 말이죠.(아직 'init'에 대해서 배우지 않으셨으면 이해가 안되는게 정상입니다. 그런가보다~ 넘어가주세여)

그리고 설정파일들은 확장자가 ".conf"로 끝나고, 뭐 요정도 정도밖에 기존 'init' 시스템에선 딱히 용도에 맞게 파일들을 구분하는게 많지 않았고, 그렇기에 '유닛(unit)'라고 부를만한 세분화가 없었습니다.

하지만 'systemd' 시스템부터는 '기존 init 기능 이외'에도 시스템 전반적인 것들을 관리하는 기능이 더 있기에, 그만큼 사용해야할 파일들도 많아졌고, 그래서 효율적으로 사용하기 위해, 'systemd'가 사용하는 파일들을 그 용도에 따라 명확히 구분(세분화)했습니다.  

그리고 세분화된 'systemd'가 사용하는 파일들을 '단위(unit)'이라고 부르기로 했죠.

여기서 세분화 했다는 것은, 용도에 따라 파일 이름 끝에 붙이는 확장자가 더욱 다양해졌다는 겁니다.

예를 들어, 우리가 알고 있는 데몬(서비스)은 파일이름 끝에 확장자 ".service"를 붙여 구분하고,  데몬 프로그램에서 사용하는 소켓 파일은 확장자 ".socket"을 붙이듯이 말이죠.

이건 아까 'init' 시스템처럼 똑같이, 'systemd'를 사용하는 시스템에서 ''sshd" 검색을 한 결과입니다.

주황색을 보시면, 그냥 'sshd'만 있던 'init'시스템과는 다르게, 'sshd.service', 'sshd.socket'이렇게 용도에 따라 나뉘어져 있는 것을 볼 수 있습니다.

그리고 이렇게 확장자가 붙어있는 sshd.service, sshd.socket을, 우린  systemd가 사용하는 파일이라 해서 단위(unit)라 부르기로 했다는 것이죠. 

이 외에도  systemd가 사용하는 파일들의 확장자 종류에는 service, socket, device, target, path, device, mount 등등 다양하게 있습니다. 

이렇듯 단위가 다양하기에 말 그대로 '단위가 다양해졌다'고 한 것입니다. 

5) 더 낮아진 실행중 필요한 메모리양(footprint)

6) 초기화 명령어들이 이젠 쉘 스크립트가 아닌 단위(unit)파일들에 적혀있음

음 이것도 사진을 보여드리자면

init을 사용하는 시스템인 경우

이렇게 초기화 명령어들이 쉘 스크립트 형식으로 적혀 있습니다.

이런 경우 쉘 스크립트를 모르는 분들은 당연히 이해할 수 없고, 무엇을 해야하는지 이해하기 위해서는 일일이 코드를 해석해야하기 때문에 조금 더 번거러운 부분이 있습니다.

하지만 systemd 시스템에서는 이런 초기화 명령어 부분들을 'systemd'에서 정의해놓은 특정한 구문을 통해서 실행합니다.(자세한건 'systemd' 포스트에서 다루겠습니다.)

미리 살짝 설명하자면, 'Description(설명)'을 통해서 이 유닛이 무슨 역할인지를 알 수 있고,

'documentation(문서)'를 통해서 이 유닛에 대한 설명이 써져있는 man 페이지를 알 수 있고,

'Requires(필요하다)'를 통해서 이 유닛(basic.target)이 실행될 때 반드시 실행되야할 다른 유닛이 'sysinit.target'이라는 '의존성'을 알 수 있고,  'after(어떤 것 다음에 실행해라)'를 통해, 현재 유닛(basic.target)은 'sysinit.target' 다음에 실행되야함을 알 수 있고... 등등

말 그대로 직관적으로 어떤 순서로 실행되며, 어떤 파일을 실행하고 등등을 알 수 있고, 설정할 수 있다는 것이죠.

7) systemd의 'calendar timer란 유닛 파일'을 이용해 job 스케줄링을 할 수 있다. 

원래 리눅스 시스템에선 'cron'이라는 유닉스 시스템 스케줄러를 이용해서 특정 시간대에 어떤 작업을 하라고, 예약을 할 수 있거든요, 'systemd'에선 '.timer'라고 끝나는 유닛을 새로 도입했고 이 '.timer'로 끝나는 유닛을 이용해서 'cron'작업을 할 수 있습니다.

8) 이벤트 기록을 'journald'라는 데몬이 한다.(sysVinit에선 syslogd가 했음)

여기서 말하는 "리눅스 시스템 이벤트란" 뭘까요? init시스템의 "man 5 init"에 적혀있는 "이벤트의 정의"는

"언제든 관리자가 initctl(init 데몬을 컨트롤할 수 있는 프로그램)의 start, stop 명령어를 사용해 시작하거나 정지할 수 있는 작업들" 라고 적혀있습니다.

그리고 원래 이 이벤트는 'init' 프로세스가 필요할 때마다 자동으로 발생하며, 이러한 이벤트 기록을 'syslogd'라는 데몬이 했습니다.

왜 'syslogd'를 안 쓰고, 'jounald'로 바꿨을까는 다른 포스트에서 다루도록 하겠습니다. 

9) 현재 시스템 상태를 그대로 저장했다가 다시 사용할 수 있는 snapshot 기능 지원(systemctl snapshot 명령어를 사용)

이것도 자세한건 나중에 따로 포스트를 해보겠습니다.(포스트 하나에 너무 많은 정보를 적으면 여러분도 읽느라 고생, 저도 고생, 블로그 측면에서도 안 좋아요 ㅠㅠ)

 

10) 프로세스들의 추적을(얼마나 자원을 사용하는지, 잘 종료 됐는지 등등) "cgroup(control group)"이란 그룹들을 이용해 한다.

이것도 다른 포스트에 정리하겠습니다.. (죄송합니다..)

11) 유저들의 로그인을 다양하게 관리할 수 있게 해주는 'systemd-logind'란 데몬을 사용

이 정도로 큼직하게 달라진 점을 말할 수 있을 것 같습니다.

---

후... 이 포스트도 생각보다 시간이 엄청 오래걸렸네요(하루 6시간, 3일 걸렸네요) 하핫... 

그리고 추가로 막상 포스트 하다보니 개인적으로 궁금한게 계속 생겨서 많이 공부하다보니, 블로그 포스트를 오랜만에 하게된 것 같습니다.

저의 노력을 갈아넣은 포스트가 꼭 도움이 되셨으면 좋겠습니다!!! 그리고 도움이 되셨다면 따뜻한 댓글 및 팔로우를 해주시면 저에게 큰 힘이 돼, 포스트 퀄리티 향상에 큰 도움을 줍니다!

그럼 다음에 'sysvinit(init 프로세스) 총 정리 포스트', 'systemd 총 정리 포스트', '리눅스 PID, 프로세스 명령어'들 중 하나로 찾아뵙겠습니다!!