system 리눅스 부팅 시작 프로세스 정리

리눅스 부팅 시작 프로세스 정리

시스템이 응용 프로그램을 실행할 준비가 되려면 무엇이 필요한지 궁금한가?

리눅스 부팅 및 시작 프로세스를 이해하는 것은 리눅스를 구성하고 시작 문제를 해결할 수 있다는 점에서 중요하다.
이 문서는 grub2 부트로더를 사용하는 부트업 시퀀스와 systemd 초기화 시스템이 동작하는 순서에 대해 간략하게 설명한다.

grub2: https://en.wikipedia.org/wiki/GNU_GRUB
system: https://en.wikipedia.org/wiki/Systemd

실제로 리눅스 컴퓨터를 부팅중 일때 필요한 두 가지 이벤트가 있다.

- 부팅 및 시작
컴퓨터 전원 ON
커널 초기화
systemd 시작

시작 프로세스는 동작/점거 상태 정보를 리눅스 컴퓨터로 가져 오는 작업을 완료한다.

전반적인 리눅스 부팅 및 시작 프로세스는 이해하기 쉽다.

- BIOS POST
- 부트로더 (GRUB2)
- 커널 초기화
- 모든 프로세스의 부모인 system를 시작

GRUB2와 system는 최근에 발표된 리눅스에서 초기화 소프트웨어로 사용되고 있다.

1 부팅 프로세스
컴퓨터 전원 ON
부팅 프로세스 시작
루트 사용자 및 일반사용자 로그인

부팅 순서 변경
재 부팅

2. BIOS POST
컴퓨터 전원 ON
BIOS(기본 입출력 시스템)의 일부인 POST(Power On Self Test) 실행.

1981년 IBM 최초의 PC 설계.
BIOS 하드웨어 구성 요소로 하드웨어 초기화 설계.
POST는 컴퓨터 하드웨어가 올바르게 동작하는지 확인하기 위함이며, BIOS의 일 부분이다.
POST가 실패하면 컴퓨터를 사용할 수 없음(즉 부팅 프로세스를 진행 불 가능)

BIOS POST는 하드웨어의 기본 동작 가능성을 검사 한 다음 연결된 모든 부팅 장치에서 부팅 섹터를 찾는다.
부팅 섹터는 BIOS 인터럽트 INT 13H를 실행한다.
유효한 부트 레코드를 포함 하는 첫 번째 부트 섹터는 RAM에 로드 된 후 제어 명령을 부트 섹터에 로드 된 코드(grub)로 전송 된다.

부트 섹터가 실제 부트 로더의 첫 단계이다.
리눅스 사용되는 부트로더 grub, grub2, lilo가 있음.

3. GRUB
GRUB2는 "GRand Unified Bootloader, version 2"의 약자이다.
현재 대부분의 최신 리눅스 배포판에서 기본 부트로더를 사용한다.
GRUB2는 컴퓨터 운영체제 커널을 찾아 메모리에 로드 할 정도로 잘 만들어진 프로그램이다.

GRUB은 멀티 부트 사양과 호환되도록 설계되었다.
https://en.wikipedia.org/wiki/Multiboot_Specification
단일 운영 체제의 부트 레코드를 변경해 로드 할 수 있다.

GRUB은 설치된 리눅스 배포본에 대해 여러 다른 커널 중 하나를 선택해 부팅 할 수 있다.
업데이트 된 커널이 부팅이 안 될 경우 또는 특정 프로그램에서 동작 안할 경우 다른 이전 버전의 커널로 부팅 할 수 있다.
이러한 구성 파일은 /boot/grub/gurb.cnf 파일을 사용해 설정 할 수 있다.

grub1은 현재 레거시로 간주되며 대부분의 리눅스 배포판에서는 grub2로 변경 되었다.
grub2는 grub1을 다시 작성한 소프트웨어 프로그램이다.
grub2는 grub1과 동일한 부트 기능을 제공한다.
grub2는 메인 프레임과 유사한 명령 기반의 미리 정해진 OS 환경이기 때문에 부팅 전 단계에서 더 많은 유연성을 제공한다.
grub2는 /boot/grub2/gurb.cfg 파일로 설정 가능하다.

두 grub의 주요 기능은 리눅스 커널을 메모리에 로드해 실행하는 것이다.
두 버전의 grub은 본질적으로 동일한 방식으로 동작하며 동일한 세 단계를 거치지 만 grub 역할을 수행하는 방법에 대한 설명을 위해 grub2를 사용한다.

4. 단계별 절차.
1 시작
- BIOS POST 섹션 동작
- POST 끝날 때 연결된 디스크 MBR(마스터 부트 레코드)에 있는 부트 레코드 검색 찾기
- 부트 레코드 메모리 로드
- 부트 스트랩 코드, 즉 GRUB2 1 단계은 파티션 테이블 함께 하드 드라이브의 첫 번째 섹터 512 바이트 맞춤.
- 마스트 부트 레코드(https://en.wikipedia.org/wiki/Master_boot_record)에서 실제 부트 스트랩 코드에 할당 된 총 공간은 446 바이트 이다
- 1 단계 446 바이트 파일의 이름은 boot.img이며 별도로 부트 레코드에 추가되는 파티션 테이블은 포함하지 않는다.

부트 레코드는 작아야 하기 때문에 파일 시스템 구조를 이해하지 못한다.
따라서 1 단계의 유일한 목적은 1.5 단계 RAM에 로드 한 후 1 단계를 1.5 단계에서 제어 전환한다.

1.5 단계
위에서 언급했듯이 grub의 1.5 단계는 부트 레코드 자체와 디스크 드라이브의 첫 번째 파티션 사이의 공간에 있어야 한다.
이 공간은 기술적 이유(역사적)로 사용되지 않고 남겨놓았다.
하드 드라이브의 첫 번째 파티션은 섹터 63에서 시작 하고 섹터 0의 MBR과 함께 62 512-바이트 섹터-31744 바이트- 남겨둔다.
GRUB은 1.5단계인 core.img 파일을 저장 한다.
core.img 파일은 25389 바이트 이므로 MBR과 이를 저장할 첫 번째 디스크 파티션 사이에 충분 한 공간이다.

이 단계에서 수용 할 수 있는 많은 양의 코드로 인해 표준 ext linux 파일 시스템, fat, NTFS와 같은 공통 파일 시스템 드라이버를 포함 할 수 있다.
grub2의 2단계에서 표준 ext 파일 시스템을 사용할 수 있지만, 논리 볼륨에는 사용할 수 없다.
따라서 2단계 파일의 표준 위치는 /boot/ 파일시스템, /boot/grub2 에 있다.

/boot 디렉토리는 grub에서 지원하는 파일 시스템에 있어야 한다.
전체 파일 시스템은 아니다.
1.5 단계의 기능은 /boot 파일 시스템에서 2 단계에서 필요한 파일을 찾고 필요한 드라이버를 로드하는 데 필요한 파일 시스템 드라이버를 실행해 시작하는 것이다.

2 단계
이 단계의 grub 관련 모든 파일은 /boot/grub2 디렉토리 하위 디렉토리에 있다.
grub2에는 1단계와 2단계와 같은 이미지 파일은 없다.
대신, 대부분은 /boot/grub2/i386-pc 디렉토리에서 필요에 따라 로드되는 런타임 커널 모듈로 구성된다.

grub2 2단계의 기능은 리눅스 커널을 찾아서 RAM에 로드하고 컴퓨터를 제어하는 것이다.
커널 및 관련 파일은 /boot/ 디렉토리에 있다.
보통 커널 파일은 vmlinuz로 시작하는 이름으로 식별 할 수 있다.
/boot/ 디렉토리의 내용을 나열하여 현재 시스템에 설치된 커널을 볼 수 있다.

grub2는 여러 리눅스 커널 중 하나를 선택해 부팅을 지원한다.

grub2의 2단계는 선택한 커널을 메모리에 로드하고 컴퓨터 제어를 커널에게 넘기는 것이다.

3 핵심
모든 커널은 공간을 절약하기 위해 압축 해제 된 자체 압축 형식으로 되어있다.
커널은 RAM 디스크 이미지 및 하드 드라이브의 장치 맵과 함께 /boot 디렉토리에 있다.

선택한 커널을 메모리에 로드하고 실행 한 후에는 RAM 디스크 압축을 풀기 전 커널 버전과 맞는 RAM 디스크 파일을 풀어야 한다.
커널이 압축을 풀면 systemd를 로드한다.
systemd는 이전 방식 sysv(BSD) init(유닉스) 프로그램을 대체하는 방식이다.

https://en.wikipedia.org/wiki/Systemd
https://en.wikipedia.org/wiki/Init#SysV-style

여기 까지가 부팅 과정이 끝이다.
이 시점에서, 리눅스 커널 및 systemd 실행 하지만, 최종 사용자는 아직 아무런 작업을 수행할 수 없다.

4. 시작 프로세스
시작 프로세스는 부팅 프로세스를 따르고, Linux 컴퓨터는 생산적인 작업에 사용할 수 있는 작동 상태를 제공 합니다.

5. systemd
systemd는 모든 프로세스의 모체이며 리눅스 호스트를 생산적인 작업을 수행 할 수 있는 상태로 만든다.
이전 init 프로그램보다 훨씬 광범위한 기능 중 일부는 파일 시스템 마운트, 시스템 서비스 시작 및 관린, 실행중인 리눅스 호스트 관리가 여러 측면에 보강 되었다.
시동 순서와 관련이 없는 systemd의 작업은 여기서는 언급하지 않느다.

먼저, systemd는 스왑 파일이나 파티션을 포함하여 /etc/fstab에 정의 된대로 파일 시스템을 마운트 한다.
이 시점에서 /etc/ 에 있는 구성 파일에 접근 할 수 있다.
구성 파일 /etc/systemd/system/default.target 을 사용하여 호스트를 부트하기 위해 상태 또는 대상을 결정 한다.
default.target 파일은 실제 대상 파일 만 심볼릭 링크한다.
데스크탑 워크스테이션의 경우 일반적으로 이전의 systemV init에서 runlevel 5와 동일한 graphical.target이 된다.
서버의 경우 기본값은 SystemV에서 실행 레벨 3과 같은 다중 사용자 모드일 가능성이 크다.
emergency.target은 단일 사용자 모드와 유사하다.

systemd 시작과 이전 버전의 systemV 시작 런레벨을 비교 한다.
halt.target: 시스템 전원을 끄지 않고 시스템 정지
0|poweroff.target|runlevel0.target: 시스템을 정지하고 전원을 끈다
S|emergency.target|:단일 사용자 모드. 실행중인 서비스가 없다. 파일 시스템이 마운트되지 않는다. 사용자가 시스템과 상호 작용할 수 있도록 복구 쉘만 주 콘솔에서 실행
1|rescue.target|runlevel1.target: 기본 시스템이며 가장 기본적인 서비스만 실행하고 기본 콘솔 구조 쉘을 마운트한다.
2||runrevel2.target: 다중 사용자, NFS, GUI 지원 하지 않는 모드
3|multi-user.target|runlevel3.target: 모든 서비스가 실행 중이자만 명령해 인터페이스 CLI 모드
4||runlevel4.target: 미사용
5|graphicla.target|runlevel5.target:GUI 다중 사용자 모드
6|reboot.target|runlevel6.target: 재부팅

default.target : 이 대상은 multi-user.target 또는 graphical.target에 대한 심볼릭 링크로 앨리어싱된다.
systemd는 항상 default.target을 사용하여 시스템을 시작한다.
default.target은 절대로 halt.target, poweroff.target, reboot.target 으로 지정하면 된다.

현 런레벨 확인.
sudo systemctl get-default
graphical.target ---> 그래픽 모드

런레벨 종류
0: poweroff.target
1: rescue.target
2,3,4: multi-user.target
5: graphical.target
6: reboot.target

런레벨 변경.
sudo systemctl set-default multi-user.target
Alt+F1 = 로그인 화면 이동.

각 런레벨 구성 파일에는 일련의 종속성이 있다.
systemd가 필요한 종속성을 시작한다.
이러한 종속성은 특정 기능 수준에서 리눅스 호스트를 실행하는 데 필요한 서비스이다.

system는 또한 레거시 SystemV init 디렉토리를 보고 거기에 시작 파일이 있는지 확인한다.
SystemV init 구성 파일이 있으면 서비스를 시작한다.

부트업 맨 페이지 확인.
http://man7.org/linux/man-pages/man7/bootup.7.html

sysinit.target 및 basic.target 은 시작 프로세스의 체크 위치로 간주 된다.
systemd가 서비스를 시작 할 때 병렬로 서비스를 동작 시키기 위한 방법으로 설계 되었다.
하지만, 더욱 유연성을 고려해 systemd 가 시작 하기전 동작 해야할 특정 서비스 실행 할 수 있다.
이러한 검사 방법으로 모든 서비스에 대해 동작 시킬 수 가 있게된다.

sysinit.target 은 종속되는 모든 유닛이 완료 처리.
모든 유닛. 마운트 파일 시스템, 스왑 파일 설정, udev 시작, 임의 생성 시드 설정, 하위 레벨 서비스 시작, 하나 이상의 파일 시스템이 암호화 되어있는 경우 암호화 서비스 설정은 sysinit 내용에 완료된다.
targeting 이러한 작업을 병렬로 처리한다.

sysinit.target는 간략한 시스템 기능 측면이 고 basic.target으로 이동 하는 데 필요한 모든 하위 수준 서비스와 장치를 시작 한다.

           local-fs-pre.target
                    |
                    v
           (various mounts and   (various swap   (various cryptsetup
            fsck services...)     devices...)        devices...)       (various low-level   (various low-level
                    |                  |                  |             services: udevd,     API VFS mounts:
                    v                  v                  v             tmpfiles, random     mqueue, configfs,
             local-fs.target      swap.target     cryptsetup.target    seed, sysctl, ...)      debugfs, ...)
                    |                  |                  |                    |                    |
                    \__________________|_________________ | ___________________|____________________/
                                                         \|/
                                                          v
                                                   sysinit.target
                                                          |
                     ____________________________________/|\________________________________________
                    /                  |                  |                    |                    \
                    |                  |                  |                    |                    |
                    v                  v                  |                    v                    v
                (various           (various               |                (various          rescue.service
               timers...)          paths...)              |               sockets...)               |
                    |                  |                  |                    |                    v
                    v                  v                  |                    v              rescue.target
              timers.target      paths.target             |             sockets.target
                    |                  |                  |                    |
                    v                  \_________________ | ___________________/
                                                         \|/
                                                          v
                                                    basic.target
                                                          |
                     ____________________________________/|                                 emergency.service
                    /                  |                  |                                         |
                    |                  |                  |                                         v
                    v                  v                  v                                 emergency.target
                display-        (various system    (various system
            manager.service         services           services)
                    |             required for            |
                    |            graphical UIs)           v
                    |                  |           multi-user.target
                    |                  |                  |
                    \_________________ | _________________/
                                      \|/
                                       v
                             graphical.target


system.target이 완료된 후 systemd는 basic.target을 시작하여 이를 수행하는 데 필요한 모든 유닛을 시작한다.
기본 목표는 다음 target(대상)에 필요한 유닛을 시작하여 몇 가지 추가 기능을 제공한다.
여기에는 다양한 실행 가능한 디렉토리 위치에, 통신 소켓 및 타이머에 대한 경로 설정과 같은 것들이 포함된다.

마지막으로, 사용자 레벨 목표 인 multi-user.target 또는 graphical.target 을 초기화 할 수 있다.

multi-user.target은 콘솔 텍스트 모드로 로그인 할 수 있다.
graphical.target이 기본이면 그래픽 로그인을 볼 수 있다.
GUI 로그인 화면은 사용 하는 기본 디스플레이 관리자에 따라 다르다.

DM: Displayer Manager
|Desktop|Display manager|설명|
|GNOME  |GDM|그놈 디스플레이 메니저|
|KDE    |KDM|KDE 기반 디스플레이 메니저|
||LightDM|조그만한 디스플레이 메니저|
|LXDE|LXDM|LXDE 디스플레이 메니저|
|KDE|SDDM|단순한 데스크탑 디스플레이 메니저|
||XDM|기본 X 윈도우 시스템 디스플레이 메니저|

WM: Windows Manager: X window System:https://en.wikipedia.org/wiki/X_Window_System
|Desktop|Window manager|설명|
|Unity|Compiz
||FluxBox||
||FVWM||
||IceWM||
|KDE|Kwin|2008년 KDE Plasma 4 시작|
|GNOME|Metacity|그놈 2의 기본값
|GNOME|Mutter|그놈 3의 기본값
||twm|아주 오래되고 간단한 창 관리자|
|Xfce|Xfwm||

요즘 새롭게 나온 WM: Windows Manager인 Wayland: https://en.wikipedia.org/wiki/Wayland_(display_server_protocol)


6. 문제점
/etc/default/grub 수정시 원하는 커널로 부팅 되지 않을 경우가 발생.
GRUB_DEFAULT = GRUB_DEFAULT = 2

수정 후 저장.
grub2-mkconfig > /boot/grub2/grub.cfg
또는
grub-mkconfig > /boot/grub/grub.cfg

7. 결론
grub2 및 systemd init 시스템은 대부분 최신 리눅스 배포판에서 사용된다.
부팅 및 시작 단계의 핵심 구성 요소이다.
특히 systemd를 둘러싼 논쟁이 있었음에도 불구하고 이 두 구성 요소는 커널을 처음 로드하고 리눅스 시스템의 기능을 생성하는 데 필요한 모든 서비스를 시작 할 수 있다.

이전 버전보다 grub2와 systemd가 더 복잡하지만, 기능을 습듭하면 관리하기가 쉽다.
systemd 메뉴얼 페이지: https://www.freedesktop.org/software/systemd/man/index.html

pci-e 리얼텍 랜카드 설정.

sudo lspci -v

커널에서 r8169 로 잡히는게 문제
r8168 드라이버를 받아서 설치
r8169 드라이버를 blacklist에 넣어 로딩하지 않게 하면 문제가 해결

8169는 pci 기반 칩셋이고 8168은 pci-e 기반 칩셋

다운로드
http://www.realtek.com/downloads/downloadsView.aspx?Langid=1&PNid=13&PFid=5&Level=5&Conn=4&DownTypeID=3&GetDown=false
linux 버전으로 2016년에 나온 것으로 다운

압축 해제 후 예전 커널 드라이버 사용하지 않기위해 blacklist 에 추가
echo "blacklist r8169" >> /etc/modprobe.d/blacklist.conf

컴파일이 안 될 경우에는 헤더가 없다는 메세지가 나온다.
즉 /lib/modules/`uname -r`/ build 심볼 링크가 없었서 그런다.
이걸 해결 하기 위해서 헤더를 설치해 준다.

sudo apt-get install linux-headers-$(uname -r)
또는
sudo apt-get install linux-generic
sudo apt-get install linux-source

참고 명령어
apt-get install linux-headers-$(uname -r)
apt-get install kernel-package
sudo apt-get update && sudo apt-get install linux-headers-3.5.0-36-generic
sudo apt-get update && sudo apt-get install linux-headers-`uname -r`

다운로드 받는 파일로 이동
rmmod r8169
네트웍 동작 하지 않음

컴파일
./autorun.sh

자동 모듈적제
depmod -a

수동 모듈 적제
insmod ./src/r8168.ko
ERROR: could not insert module ./src/r8168.ko: File exists --> 모듈이 적제 되었다는 의미

램디스크 드라이버 추가
mkinitramfs -o /boot/initrd.img-'uname -r' 'uname -r'

부팅시 자동 적재
echo "r8168" >> /etc/modules

재부팅
reboot

확인
lsmod | grep r8168

우분투 설치 이미지 관련

우분투 설치 이미지 관련
http://archive.ubuntu.com/ubuntu/dists/bionic-updates/main/installer-amd64/current/images/

Live : CD/DVD 또는 USB에서 부팅
cdrom : CD로 부팅후 HDD 설치.
hd-media: ISO 부팅 후 HDD 설치.

영국의 캐노니컬에서 개발하는 우분투 14.04 리눅스 커널의 새로운 기능 추가나 버그 수정 또는 보안 취약점 문제 해결한 HWE 커널 4.4.0-119 버전이 업데이트를 통해 배포

*LTS : Long Term Support - 5년 간의 장기 지원
*HWE : Hardware Enablement - 하드웨어 지원 강화를 위한 커널로, 6개월마다 4번에 걸쳐 판올림하면서 지원
*GA : General Availability - 출시 당시의 커널로, 5년 간 판올림 없이 지원

hwe-cdrom: CD로 부팅후 HDD 설치.
hwe-hd-media: ISO 부팅 후 HDD 설치.
hwe-netboot: 네트워을 통한 설치

우분투 버전 04, 10 차이점

16.04 LTS, Long Term Release 버전 5년간 지원

16.10버전 9개월 지원

systemd

새로운 PID 1, systemd ?

ConsoleKit(udev, mdev, dev) 변천 과정에서 생기는 방식으로 추정됨.
즉 부팅시 프로세스 관리 방법을 변경 되어진다. Systemd 방식

데비안이 다음 버전 init으로 systemd를 선택했고 우분투도 따라가는 것 같다.
RHEL - 버전 7부터
CentOS - 마찬가지
Fedora - 가장 처음 systemd를 기본으로 채택
Arch
openSUSE
SLES - 버전 12부터
Debian
Ubuntu - 채택
systemd가 새로운 대세가 된.

ConsoleKit
- Session
  하나의 부모에서 파생되는 특정 프레세스들의 집합,
  환경 변수를 공유하므로 한 유저 이상이 같은 세션을 공유하는건 불가능함.

- Seat
  Sear는 여러 세션과 하드웨어 자원을 엮어놓은 상위 집합이라고 할 수 있다.
  기존 권한관리 시스템을 이용하면 그룹이나 오너가 아니면(보통 root) 하드웨어 자원을 사용하기가 어렵고 보안상의 문제도 있었지만,
  이를 해결 할 수 있는 방법으로 seat를 통해 하드웨어를 자원을 이용할 수 있게 하는 것 같다.(는 내 생각)

보통 이런 방식으로 보안 로그를 확인 한다.
즉, 보안에 관련된 프로세스(서비스하고 있는 프로세스)에 대한 로그를 만들어 그 로그를 보고 보안상에 이슈를 확인하는 방식으로
보안 장비들이 만들어진다.

systemd와 consolekit를 같이 설치할 수 없다는 에러메시지 둘중 하나를 선택해서 사용해야 한다.
consolekit는 더이상 관리되지 않기 때문에 안쓰는게 좋다는 얘기가 보였다.

systemd 가 기존의 init 시스템인 OpenRC 를 대체한다는 점이다.
즉 시스템의 부팅을 관장하는 프로그램이 바뀌는 것이 때문에 무턱대로 설치할 수도 없는 노릇이었다.
그래서 우선 systemd 로 왜 바꾸는지, 그리고 이게 도데체 무엇인지 좀 알아봤다.

여기서 부터 퍼온글인데... 2014년에 전리한 문서라서. 출처를 모르겠음.

systemd는 오랫동안 사용되어 온 shell script 기반의 init 시스템을 대체하기 위해 만들어졌다.
가장 큰 특징은 부팅시에 띄워야 하는 서비스 수를 최대한 줄이고,
서비스 간의 의존성을 없애서 서비스들을 병렬로 실행하게 함으로써 부팅속도를 획기적으로 개선했다는 점이다.
가령 bluetoothd 와 같은 daemon은 블루투스 동글이 접속되지 않은 이상 꼭 떠야할 필요는 없다.
즉 그것이 필요할 때까지 최대한 기다려서 띄우는 방식이라 꼭 부팅 때 실행할 필요가 없게 만든 것이다.
또 서비스 간의 의존성이란, 예를 들어 D-Bus가 실행되려면 로그시스템인 syslog가 먼저 준비되어 있어야 하는 경우처럼 순차적으로 꼭 실행해야하는 것을 의미한다.
하지만 systemd는 이 부분을 각 서비스가 의존하고 있는 선행 서비스에서 꼭 필요한 부분이 그 서비스 전체가 아니라 소켓이라는 사실을 이용하여 해당 소켓을 먼저 생성해 두고,
경우에 따라 들어오는 시그널은 소켓 버퍼에 쌓아두었다가 해당 서비스가 준비 완료되면 그것을 처리하게 해주는 방식으로 의존성을 낮추었다고 한다.

암튼 이런 기발한 방법으로 시스템의 부팅속도를 높였다.
이런 장점 외에도 대부분 c로 구현되어 있어서, 실행중 사용하는 다른 유틸리티들 때문에 수시로 포크가 일어나는 shell script 기반의 실행속도 보다 훨씬 빠르다고 한다.
이런 저런 이유로 최근 배포판들의 대세가 된 듯한데…

이거 반대하는 쪽도 꽤 있나보다.
systemd 메인개발자 중 한명이 PulseAudio 개발자인데 이걸 싫어하는 사람들이 systemd도 싫어하는 듯 하다(나는 PulseAudio의 내력을 잘 몰라서 뭐가 문제인지 모르겠다).
그런데 그들의 주장 또한 일리가 있는 듯 한다.
우선 systemd가 이식성이 낮아서 리눅스에만 적용할 수 있다는 점이다.
Debian의 경우
커널을 리눅스 뿐만 아니라 FreeBSD나 Hurd 버전도 있기 때문에 systemd을 default로 적용하기 어렵다고 한다.
또 다른 이유로는 소켓 preallocation 관련하여 각 데몬들에 패치를 적용해야한다는 점이다.

만약 Systemd를 사용한다면
systemd로 바꾸게 되면 기존의 SysVinit - /sbin/init은 물론 /etc/init.d/*, /etc/rc*.d 이런 디렉토리에 있는 데몬 관리용 스크립트들과 배포본별로 제공하던 런레벨 관리자도 사용하지 않습니다.
패키지별로 systemd 방식의 설정 파일을 /usr/lib/systemd/ 아래에 설치하고 systemctl 명령어를 통해 시작/중지/등록/삭제 작업을 합니다.
데몬의 상태를 관리하는 일도 합니다.
죽거나 멈추면 다시 시작해주고 다양한 조건에 따라 중지하거나 시작하거나 하는 일도 합니다.
설정 파일의 형식은 .ini 파일이나 .desktop 파일 하고 비슷합니다.
각 데몬의 출력 - 로그는 journald에서 일괄적으로 처리해서 journalctl 명령어로 조회하거나 별도의 로그 데몬으로 전달할 수 있습니다.

그런데 단순히 /sbin/init을 대체하고 데몬 관리만 하는 것은 아니더군요.
세부적인 설명은 제가 기술이 짧아서 언급하기 힘듭니다만 그동안 systemd 관련 글타래를 훑어본 결과로는 온갖 바닥 일은 systemd가 다 할 수 있는 것 같습니다.

동적인 장치 관리, 사용자 인증, 권한 관리, 프로세스별 자원(cgroup) 관리, 로그 관리, 사용자별 서비스 등등 별 별거 다 하더군요.

systemd의 구현 방식이 좋다 나쁘다 할 지식은 없지만 어쨌든 systemd 광고대로 잘 되면 배포본별로 제각기 다른 시스템 관리 작업이 통합된다는 점은 저한테 큰 장점으로 보입니다.
mysql, apache 다시 시작하는데 배포본마다 다른 방법을 사용해야 한다는 게 좋은 일만은 아니질 않습니까?
어차피 패키지 업스트림은 다 같은 데서 가져다 쓰는 데 사용하는 방식도 통일될 수 있다면 좋은 일이 아닐까 합니다.

데스크탑 사용자의 입장에서 systemd로 돌아가는 배포본을 써보면 당장 피부에 와 닿는 느낌은 없습니다.
아치 리눅스 써 본 경험에 의하면 시스템 종료가 우분투보다 빠르다?
그것이 systemd 때문인지도 확실하진 않습니다. 부팅도 우분투와 비교하여 좀 빠른 감은 있는데 큰 차이는 아니었습니다.

systemd의 관한 논쟁 중에 재밌는 점은 개발자
- Lennart Poettering -
개인에 관한 공격이 많다는 겁니다. 이 분은 pulseaudio 개발자이기도 한데 개발 과정에서 안 좋은 인상을 남겼는지 삐딱하게 보는 시선이 상당히 많이 보였습니다.

기술적인 측면이 아닌 개발자 개인의 성향에 관한 비판이 어떤 면에서는 유치한 공격이 아닌가 할 수도 있습니다만 시선을 바꿔서 바라보면 또한 일리가 있습니다.

systemd가 담당하는 부분은 커널을 제외하고는 가장 핵심적인 부분이고 밑바탕이라고 볼 수 있습니다.
한 번 선택하면 쉽게 다른 패키지로 대체할 수 없고 적어도 5년, 10년은 바라봐야 하는 그런 패키지라고 생각합니다.
이런 중요한 패키지의 핵심 개발자가 커뮤니티와 의사소통이 잘 안 되고 프로젝트 관리 방식이 편협하거나 독재적인 성향이 강하다면 큰 골칫거리가 될 수 있습니다.
그래서 개발자의 개인적인 성향도 해당 소프트웨어를 선택하는 데 중요한 이유가 되는 것이 맞는다고 생각합니다.

Lennart의 개발자로서의 성향은 잘 모르나 여하튼 pulseaudio를 사용하면 받은 인상은 나쁘지 않기 때문에 전 별다른 유감은 없습니다.

기술적인 측면에서의 비판은 '한 가지만 잘하자'는 유닉스의 철학에 너무 어긋나는 설계다,
너무 많은 일을 한군데서 담당한다는 의견을 자주 보였습니다. 이 문제는 '한 가지'를 어떻게 정의하느냐에 따라 다양한 해석이 가능할 것 같습니다.

기존의 sysv 스타일의 시스템도 많이 다뤄 보시고 systemd도 만져 보신 분들이 있으신가 궁금합니다.
어떤 장단점이 있는지 들어 보고 싶네요.

제 경우 손에 잘 달라붙는 유용한 명령들은 journalctl로 특정 서비스 로그 골라보기하고 systemctl status로 역시 특정 서비스 상태 골라 보기가 맘에 들었습니다.
이전에도 가능했던 작업이지만 더 편하게 볼 수 있어서 좋더군요.

데비안이 어떤 결정을 할 지도 참 궁금합니다.
데비안과 우분투도 systemd를 선택하면 리눅스 세계에서 꽤 기념비적인 '대통합'으로 기억될 것 같습니다.

정리하면.
systemd로 서비스 관리
서비스 로그 확인 명령어: journalctl
프로세스 상태 확인: systemctl status

원격 접속

aptitude install gnome-rdp

옵션은 아래 ...
-u: user name
-p: password (- to prompt)
-k: keyboard layout on server (en-us, de, sv, etc.)
-g: desktop geometry (WxH)
-f: full-screen mode
$ rdesktop -a 16 -u XXX -p YYY -k ko -g 1024x768 192.168.123.123

윈도우 설정.
컴퓨터 -> 속성
원결설정
① [이 컴퓨터에 대한 원격 지원 연결 허용]에 체크를 합니다
② 모든 버전의 원격 데스크톱을 실행 중인 컴퓨터에서 연결 허용(보안 수준 낮음)을 선택합니다.

포트 개방 (윈도우 7)
1. 방화벽 창에서, 고급 설정을 클릭한다.
2. 좌측 메뉴에서 인바운드 규칙을 클릭하고, 우측 메뉴에서 새 규칙을 클릭한다.
3. 규칙 종류에서, 포트를 선택하고 다음을 클릭한다.
4. 프로토콜 및 포트에서, TCP/UDP를 선택하고 특정 원격 포트에서 개방할 포트를 입력한 후 다음.
5. 작업에서, 연결 허용을 선택하고, 다음을 클릭한다.
6. 프로필에서, 적용되는 곳을 선택하고 다음을 클릭한다. 기본으론 3개 다 선택되어있음.
7. 이름에서, 알아볼 수 있는 이름을 입력하고, 설명에선 간단한 주석을 달아 놓은 뒤 마침을 클릭한다.
8. 아웃바운드 규칙에도 3~7 과정을 그대로 추가한다.


접근 방식
https://kldp.org/node/99781

FreeNX
tsclient

윈도우에서 리눅스 접속 방법.
http://forum.falinux.com/zbxe/index.php?document_srl=780453&mid=lecture_tip
리눅스
apt-get install xrdp
바탕 화면 구성, 메뉴 나오지 않음.
Unity 3D 비지원시 메뉴 화면 구성 문제.

unity 2D 버전으로 동작
$ sudo vi ~/.xsession
gnome-session --session=ubuntu-2d

윈도우 원격데스크탑 프로그램 실행
IP: 주소입력

SI

시스템 통합 이야기 하는 곳