Upstart의 장점과 단점은 무엇입니까?


183

몇 년 전 Upstart 와 마찬가지로 systemd 가 블록의 최신 init 시스템 인 것처럼 보입니다 . 각각의 장단점은 무엇입니까? 또한 각각 다른 init 시스템과 어떻게 비교됩니까?


4
@keith IIRC openrc 단순히 시스템 V는 장점은 좋은 정리,하지만 정말 새로운 initd 공통 구성 요소를 사용하고 (모든 쉘에 일을 의미) 이식 시작 스크립트의 잘 설계된 모음입니다 사용
xenoterracide

@xeno 그것은하지만 실제로 말할 수는 없습니다. rcX.d 또는 [KS] 심볼릭 링크가 전혀 없습니다. 실제로 sysv init 자체는 상당히 유연하며 런레벨은 실제로 일반적인 방식으로 사용되지 않습니다.
Keith

이 블로그의 저자는 체계적으로 작성되어 있지는 않지만이 기사를 읽도록 제안합니다. systemd와 BSD init의 장단점을 다룹니다. textplain.net/blog/2015/…
Peschke

1
2016 업데이트 unix.stackexchange.com/a/287282/49091 도 참조하십시오.
igaurav

systemd의 모든 장점은 100 년 안에이를 구현하기 위해 이미 발생하는 비용을 상쇄하지 않을 것입니다. 이 쓰레기를 처리하기 위해 유닉스 관리자가 소비 한 1 분 또는 1 시간 또는 1 일마다 이미 수십억 달러를 더해야하며 몇 가지 종과 휘파람 외에 다른 실질적인 이점이 있습니까?
Waslap

답변:


90

2016 년 업데이트

여기에있는 대부분의 답변은 5 살이므로 업데이트 할 때입니다.

우분투는 기본적으로 upstart를 사용했지만 작년에 systemd를 선호하여 포기했습니다.

그 때문에 Ubuntu Wiki의 Upstart 사용자위한 Systemd 기사 가 있습니다. upstart와 systemd 사이의 매우 상세한 비교와 upstart에서 systemd 로의 전환 안내서입니다.

( 우분투 위키에 따르면 기본적으로 설치 upstart-sysv하고 실행 하여 현재 버전의 우분투에서 여전히 시작할 수 sudo update-initramfs -u있지만 시스템 프로젝트의 범위를 고려하면 실제로 어떻게 작동하는지 또는 시스템화 여부는 알 수 없습니다. 제거 가능)

아래의 명령 및 스크립트 섹션에있는 대부분의 정보는 해당 기사에서 사용 된 일부 예제 ( Creative Commons Attribution-ShareAlike 3.0 라이센스 에 따른 Stack Exchange 사용자 기여와 마찬가지로 라이센스가 부여 된 )에서 수정되었습니다.

다음은 일반적인 명령과 간단한 스크립트를 간단히 비교 한 것입니다. 자세한 설명은 아래 섹션을 참조하십시오. 이 답변은 질문에서 설명한 것처럼 Upstart 기반 시스템의 이전 동작과 시스템 기반 시스템의 새로운 동작을 비교하지만 "Upstart"로 태그가 지정된 명령은 반드시 Upstart에만 해당되는 것은 아니라는 점에 유의하십시오. 모든 비 시스템 Linux 및 Unix 시스템에 공통입니다.

명령

su를 실행 :

  • 건방진 녀석: su
  • 체계화 : machinectl shell

(아래 "su 명령 교체"섹션 참조)

실행 화면 :

  • 건방진 녀석: screen
  • 체계화 : systemd-run --user --scope screen

(아래의 "배경 프로세스의 예기치 않은 종료"섹션 참조)

tmux 실행 :

  • 건방진 녀석: tmux
  • 체계화 : systemd-run --user --scope tmux

(아래의 "배경 프로세스의 예기치 않은 종료"섹션 참조)

작업 foo 시작 :

  • 건방진 녀석: start foo
  • 체계화 : systemctl start foo

foo 직업 중지 :

  • 건방진 녀석: stop foo
  • 체계화 : systemctl stop foo

작업 foo 재시작 :

  • 건방진 녀석: restart foo
  • 체계화 : systemctl restart foo

채용 공고 :

  • 건방진 녀석: initctl list
  • 체계화 : systemctl status

작업 foo 구성 확인 :

  • 건방진 녀석: init-checkconf /etc/init/foo.conf
  • 체계화 : systemd-analyze verify /lib/systemd/system/foo.service

작업 환경 변수 나열 :

  • 건방진 녀석: initctl list-env
  • 체계화 : systemctl show-environment

작업 환경 변수 설정 :

  • 건방진 녀석: initctl set-env foo=bar
  • 체계화 : systemctl set-environment foo=bar

작업 환경 변수 제거 :

  • 건방진 녀석: initctl unset-env foo
  • 체계화 : systemctl unset-environment foo

로그

시작시 로그는 / var / log / upstart 디렉토리의 일반 텍스트 파일이므로 평소와 같이 처리 할 수 ​​있습니다.

cat /var/log/upstart/foo.log
tail -f /var/log/upstart/foo.log

시스템 로그에서 텍스트 파일이 아닌 내부 이진 형식으로 저장되므로 journalctl명령을 사용 하여 액세스해야합니다.

sudo journalctl -u foo
sudo journalctl -u foo -f

스크립트

작성된 upstart 스크립트/etc/init/foo.conf:

description "Job that runs the foo daemon"
start on runlevel [2345]
stop on runlevel [016]
env statedir=/var/cache/foo
pre-start exec mkdir -p $statedir
exec /usr/bin/foo-daemon --arg1 "hello world" --statedir $statedir

작성된 시스템 스크립트 예제 /lib/systemd/system/foo.service:

[Unit]
Description=Job that runs the foo daemon
Documentation=man:foo(1)
[Service]
Type=forking
Environment=statedir=/var/cache/foo
ExecStartPre=/usr/bin/mkdir -p ${statedir}
ExecStart=/usr/bin/foo-daemon --arg1 "hello world" --statedir ${statedir}
[Install]
WantedBy=multi-user.target

su 명령 교체

su명령 교체는 풀 요청 # 1022에서 systemd에 병합되었다 :

Lennart Poettering에 따르면, "su는 실제로 깨진 개념" 입니다.

그는 "이전처럼 su와 sudo를 사용할 수는 있지만 완전히 작동 할 것이라고 기대하지는 않는다 "고 설명했다 .

su비슷한 행동을 하는 공식적인 방법은 다음 과 같습니다.

machinectl shell

Lennart Poettering 은 # 825 문제에 대한 토론에서 추가로 설명했습니다 .

"글쎄, 이것에 대한 긴 토론이 있었지만 문제는 su가해야 할 일이 매우 명확하지 않다는 것입니다. [...] 긴 이야기는 짧습니다 : su는 정말 깨진 개념입니다. 을 사용하는 것이 좋지만 전체 로그인이 아니며 오해해서는 안됩니다. " -Lennart Poettering

또한보십시오:

백그라운드 프로세스의 예기치 않은 종료

다음과 같은 명령 :

더 이상 예상대로 작동하지 않습니다 . 예를 들어, nohup세션에서 로그 아웃 한 후 프로세스가 계속 실행되도록하는 POSIX 명령입니다. 그것은 더 이상 작동하지 않습니다 systemd에. 또한 같은 프로그램 screen과는 tmux특별한 방법으로 호출 될하거나 필요 당신이 그들과 함께 실행되는 프로세스가 죽게됩니다 (처음에 화면이나 TMUX를 실행의 주요 이유는 일반적으로 살해하는 과정을받지 동안).

이것은 실수가 아니며, 의도적 인 결정이므로 향후 수정 될 가능성은 없습니다. 이것이 Lennart Poettering 이이 문제에 대해 말한 것입니다.

필자의 관점에서 볼 때 유닉스에서는 기본적으로 임의의 사용자 코드가 제한되지 않은 상태로 유지되는 것이 실제로 이상했다. 지금까지 많은 OS 사용자들 사이에서 논의되어 왔지만, 이것이 반드시 가능해야하지만 확실히 기본값은 아니지만, 스위치를 기본 설정에서 옵션으로 설정하기 위해 스위치를 뒤집는 사람은 아무도 없습니다. 로그 아웃 후 사용자 세션을 정리하지 않는 것은 추악하고 다소 해킹 일뿐만 아니라 보안 문제이기도합니다. systemd 230은 이제 스위치를 뒤집었고, 기본적으로 사용자가 로그 아웃 할 때 모든 것을 올바르게 정리합니다.

자세한 내용은 다음을 참조하십시오.

고급 스타트 업 개념

시스템 작업이 거꾸로 작동하는 방식-시작 작업은 가능한 빨리 시작하고 시스템 작업은 필요할 때 시작합니다. 하루가 끝나면 동일한 작업을 두 시스템 모두에서 거의 동일한 순서로 시작할 수 있지만, 반대 방향에서 바라 보는 것에 대해 생각합니다.

다음은 Upstart 사용자를위한 Systemd의 설명입니다.

프로세스 (작업) 시작을위한 Upstart 의 모델은 "욕심 많은 이벤트 기반"입니다. 즉, 시작 이벤트가 발생하는 모든 사용 가능한 작업이 가능한 빨리 시작됩니다. 부팅하는 동안 upstart는 시작 또는 rcS와 같은 일부 초기 이벤트를 "트리 루트"로 합성하고 초기 서비스는 해당 서비스에서 시작하며 이후 서비스는 이전 서비스가 실행될 때 시작됩니다. 새로운 작업은 구성 파일을 / etc / init /에 설치하기 만하면됩니다.

프로세스 (단위)를 시작하기위한 systemd 의 모델은 "게으른 의존성 기반"입니다. 즉, 다른 시작 단위가 의존하는 경우에만 단위가 시작됩니다. 부팅하는 동안 systemd는 "루트 장치"(default.target, grub에서 재정의 할 수 있음)를 시작한 다음 전 이적으로 확장하여 종속성을 시작합니다. 새 장치는 부팅 순서의 장치 (일반적으로 multi-user.target)의 종속성으로 자체를 추가해야합니다.

배포판에서의 사용법

이제 Wikipedia에 따르면 최근 데이터 :

기본적으로 upstart를 사용한 배포 :

기본적으로 systemd를 사용한 배포 :

( 최신 정보는 Wikipedia 를 참조하십시오 )

Upstart 또는 systemd를 사용하지 않는 배포 :

논쟁

과거 에는 데비안 포크가 체계화를 피하기 위해 제안되었습니다 . Devuan GNU + 리눅스 생성 - systemd없이 데비안의 포크 (덕분에 fpmurphy1 의견에서 지적에 대한).

이 논쟁에 대한 자세한 내용은 다음을 참조하십시오.

많은 사람들이 이미 알고 있듯이 Ian Jackson이 홍보 한 Init GR 데비안 투표는 데비안의 레거시와 그 사용자를 체계적인 눈사태로부터 보호하는 데 유용하지 않았습니다.

이 상황은 사실상 개발의 자유를 위협하고 데비안, 업스트림 및 다운 스트림에 심각한 결과를 초래하는 체계적인 종속성의 잠금을 예상합니다.

CTTE는 의존성을 바꾸고 sysvinit를 통해 시스템을 미묘하게 설치하는 데 시간을 들일 수 있었지만이 프로세스조차도 지쳐 버렸습니다. 일주일 전 이안 잭슨이 사임했다. [...]

기술위원회에서 즉시 사임합니다.

나와 동의하는 프로젝트의 30-40 %에 대한 견해를 TC에 계속 표시해야하는 것이 중요하지만, 본인은이 시점에서 분명히 논란의 여지가있는 인물입니다. 프로젝트 거버넌스에 대한 대화가 개인화되는 정도를 줄이려고 노력해야합니다. [...]

데비안은 데비안의 기본 초기화 시스템으로 사용하기로 결정한 것에 대한 논쟁에서 태어났습니다. systemd에 대한 공식 데비안 입장다른 사람들이 덤벼 들었다 는 주장들로 가득 차 있습니다 . 관심있는 독자는 체계적인 논쟁 에서이 뜨거운 주제를 계속 논의 할 수 있습니다 . 그러나 우리는 당신의 머리를 시원하게 유지하고 목소리를 시민으로 유지하는 것이 좋습니다. Devuan에서는 우리를 되돌아 보는 것보다 잘못 프로그래밍하는 데 더 관심이 있습니다. [...]

체계적인 논쟁에 전념하는 일부 웹 사이트 및 기사가 작성되었습니다.

해커 뉴스에 대한 흥미로운 토론 이 많이 있습니다 .

다른 배포판에서도 비슷한 경향이 관찰 될 수 있습니다.

철학

upstart 는 DOTADIW의 "유일한 일을 잘해라"는 Unix 철학을 따릅니다. 기존의 init 데몬을 대체합니다. 서비스를 시작하고 중지하는 것 외에는 아무것도하지 않습니다. 다른 작업은 다른 특수한 하위 시스템에 위임됩니다.

systemd 는 그 이상을 수행합니다. 서비스를 시작 및 중지하는 것 외에도 암호, 로그인, 터미널, 전원 관리, 공장 재설정, 로그 처리, 파일 시스템 마운트 지점, 네트워킹 등을 관리 합니다. 일부 기능 은 뉴스 파일을 참조하십시오 .

확장 계획

GNOME.asia에서 2014 년 Lennart Poettering이 체계적으로 달성 한 것, 그리고 앞으로 있을 것의 프리젠 테이션에 대한 관점에 따르면 , 체계화 된 주요 목표, 이미 다루어 진 영역 및 아직 진행중인 영역은 다음과 같습니다.

체계적인 목표 :

우리의 목표

  • Linux를 많은 비용에서 경쟁적인 범용 운영 체제로 전환
  • 인터넷의 차세대 OS 구축 배포 간의 무의미한 차이를 통합
  • 핵심 OS로 혁신을 가져오다

  • 데스크탑, 서버, 컨테이너, 임베디드, 모바일, 클라우드, 클러스터,. . . 이 영역들은 생각보다 서로 가깝습니다

  • 감독없이 관리자의 복잡성, 안정성 감소
  • 조사 할 수없는 모든 것
  • 자동 검색, 플러그 앤 플레이가 핵심
  • 우리는 파손 된 부분을 고정시키고 절대로 테이프로 덮지 않습니다.

이미 다루어 진 영역 :

우리가 이미 다루고있는 것 :

초기화 시스템, 저널 로깅, 로그인 관리, 장치 관리, 임시 및 휘발성 파일 관리, 이진 형식 등록, 백라이트 저장 / 복원, rfkill 저장 / 복원, 부트 차트, 미리 읽기, 암호화 된 스토리지 설정, EFI / GPT 파티션 검색, 가상 머신 / 컨테이너 등록, 최소 컨테이너 관리, 호스트 이름 관리, 로케일 관리, 시간 관리, 랜덤 시드 관리, sysctl 변수 관리, 콘솔 관리,. . .

진행중인 작업:

우리가 작업하고있는 것 :

  • 네트워크 관리
  • 시스템 네트워크
  • 로컬 DNS 캐시, mDNS 응답기, LLMNR 응답기, DNSSEC 확인
  • 커널의 IPC
  • kdbus, sd- 버스
  • NTP와 시간 동기화
  • systemd-timesyncd
  • 컨테이너와 더 통합
  • 서비스 샌드 박스
  • 앱의 샌드 박싱
  • OS 이미지 형식
  • 컨테이너 이미지 형식
  • 앱 이미지 형식
  • 자동 검색 기능이있는 GPT
  • 상태 비 저장 시스템, 인스턴스화 가능 시스템, 공장 초기화
  • / usr은 OS입니다
  • / etc는 (선택적) 구성입니다
  • / var은 (선택적) 상태입니다
  • 원자 노드 초기화 및 업데이트
  • 클라우드와 통합
  • 노드 간 서비스 관리
  • 검증 가능한 OS 이미지
  • 펌웨어까지
  • 부팅 로딩

이 답변의 범위

으로 fpmurphy1이 코멘트에 언급, "systemd 훨씬 넘어 단순히 년간 시스템 시작의를 작업의 범위를 확대하고 있다고 지적한다."

여기에 관련 정보의 대부분을 포함 시키려고 노력했습니다. 여기서는 질문에 나와있는 것처럼 init 시스템으로 사용될 때 Upstart 및 systemd의 공통 기능을 비교하고 있으며 Init 시스템의 범위를 넘어서는 systemd의 기능 만 언급합니다. 두 프로젝트의 차이점을 이해합니다. 자세한 내용은 관련 문서를 확인해야합니다.

더 많은 정보

자세한 정보는 다음에서 찾을 수 있습니다.

엑스트라

LinOxide 팀이 만든 시스템 V 초기화 리눅스 쪽지 대 Systemd을 .


4
... 그리고 그런 데비안 포크가 생겼습니다. Devuan GNU + Linux는 시스템이없는 데비안 포크입니다.
fpmurphy

2
systemd는 단순한 시스템 시작의 범위를 넘어 수년에 걸쳐 작업 범위를 확장했음을 지적해야합니다.
fpmurphy

1
뛰어난 게시물이며 Cent 사람에게 매우 도움이됩니다. 시간 내 주셔서 감사합니다 !!!
origin1tech

4
@ronsmith는 service <foo> start/stop/restart/status여전히 잘 작동합니다. 대부분의 유닉스 소프트웨어와 마찬가지로 systemd는 잘 알려진 기본값에 대한 명령 호환성을 제공합니다.
Shadur

2
아주 좋은 대답입니다. 한 가지 요점 : BSD 운영 체제는 Linux 배포판이 아닙니다. 커널이 다른 유닉스 운영 체제입니다.
Giorgio

68

upstart와 systemd는 전통적인 SysV init 시스템의 한계와 관련된 일부 문제를 해결하려는 시도입니다. 예를 들어, 일부 서비스는 다른 서비스 이후에 시작해야합니다 (예 : 네트워크가 실행될 때까지 NFS 파일 시스템을 마운트 할 수 없음). SysV에서 처리 할 수있는 유일한 방법은 rc # .d 디렉토리에 링크를 설정하는 것입니다. 한 사람이 다른 사람보다 먼저 또한 종속성을 추가하거나 변경할 때 나중에 모든 항목의 번호를 다시 매겨 야 할 수도 있습니다. Upstart 및 Systemd에는 요구 사항을 정의하기위한보다 지능적인 설정이 있습니다. 또한 모든 것이 일종의 쉘 스크립트이며 모든 사람이 최고의 초기화 스크립트를 작성하는 것은 아니라는 문제가 있습니다. 이는 또한 시작 속도에 영향을줍니다.

systemd의 장점 중 일부는 다음과 같습니다.

  • 시작된 모든 프로세스는 자체 cgroup 또는 특정 cgroup을 갖습니다.
  • xinetd가 서비스를 수행하는 방식과 유사하게 서비스를위한 사전 소켓 및 파일 핸들 작성으로 종속 서비스를 더 빨리 시작할 수 있습니다. 예를 들어, systemd는 syslog의 / dev / log에 대한 파일 핸들을 열어두고, / dev / log로 보내는 후속 서비스는 syslogd가 인수 할 준비가 될 때까지 메시지를 버퍼링합니다.
  • 실제로 서비스를 시작하기 위해 더 적은 프로세스가 실행됩니다. 이것은 서비스를 시작하기 위해 쉘 스크립트를 작성하지 않음을 의미합니다. 이것은 속도 향상 일 수 있으며 (IMO) 처음에 설정하기가 더 쉽습니다.

내가 아는 한 가지 단점은 systemd의 소켓 / FH 사전 할당을 이용하려면 systemd가 FH를 전달하도록 많은 데몬을 패치해야한다는 것입니다.


13
PulseAudio는 원래 시스템 제작자 인 Lennart Poettering이 작성한 상당히 악의적 인 사운드 시스템 ( pulseaudio.org )입니다. 펄스 오디오에 대해 불평하기를 좋아하는 여러 사람들을 알고 있기 때문에 나는 대부분 여기에서 농담을했습니다. 솔직히 시스템 또는 펄스 오디오에 문제가 없었습니다.
jsbillings

4
Plan9의 풍부한 피오르드를 위해 거의 하나의 소나무를 만듭니다 ... 모든 것이 파일입니다.
dhchdhd

4
솔직히 말해서, pulseaudio는 존재하지 않는 문제에 대한 해결책이었습니다. ALSA가 할 수없는 PA는 할 수있는 일이 없으며 PA에 문제가있는 사람들이 많이 반복해서 들었습니다.
WhyNotHugo

3
놓친 두 가지 시스템 단점 : (1) 모든 시작 스크립트를 다시 작성해야합니다. (2) 리눅스가 아닌 OS (예 : BSD)와의 호환성이 떨어집니다.
WhyNotHugo

8
그냥 좋아요 0pointer.de/blog/projects/the-biggest-myths를 살펴 보십시오 . 나는 체계적인 성장을 목격했으며 여기에 주어진 많은 비판이 완전히 근거가 없음을 증명할 수 있습니다. 링크에서 당신은 타격에 의한 타격, 찾을 합리적인 반박을.
vonbrand

30

systemd에 언급 아치 일반 ML 오늘. 따라서 읽어보십시오. H Online 은 Linux 기술의 훌륭한 소스이며 SysV Init 및 Upstart 대안으로 Systemd를 연구 할 수있는 곳을 찾았습니다 . 그러나 H Online 기사 (이 경우)는 그다지 유용하지는 않지만 실제 사용은 유용한 정보에 대한 링크를 제공한다는 것입니다.

진정한 답은 systemd 발표입니다 . 이는 SysV initd의 문제점과 새로운 시스템이 수행해야 할 사항에 대한 중요한 포인트를 제공합니다.

  • 덜 시작합니다.
  • 그리고 더 병렬로 시작합니다.

이 작업을 수행하는 주요 계획은 필요한 서비스 만 시작하고 해당 서비스에 대한 소켓을 시작하여 데몬이 완전히 온라인 상태가되기 전에 생성 된 소켓에 연결할 수 있도록 필요한 서비스를 시작하는 것 같습니다. 분명히 소켓은 적은 양의 버퍼링 된 데이터를 유지하므로 지연 시간 동안 데이터가 손실되지 않으며 데몬이 온라인이되는 즉시 처리됩니다.

계획의 또 다른 부분은, 당신이 당신을 기다리고하지 않을 그런 식으로 파일 시스템을 직렬화, 대신뿐만 아니라 수요에 사람들을 탑재하지 않는 것으로 보인다 /home/등 (와 혼동하지 /etc마운트)를, 및 / 또는 fsck당신이 할 수있을 때 같은 데몬을 시작 /하고 /var/등, 이미 장착되어있다. 이를 위해 autofs를 사용할 것이라고 말했다.

또한 .desktop스크립트를 대신 하여 스타일 초기화 디스크립터를 작성한다는 목표를 가지고 있습니다. 이것은 느린 톤 방지 할 sh프로세스와 같은 것들에서 프로세스의 더 포크 sedgrep그 종종 쉘 스크립트에서 사용됩니다.

또한 요청 될 때까지 일부 서비스를 시작하지 않을 계획이며, 더 이상 필요하지 않은 경우 서비스를 종료 할 수도 있습니다. 블루투스 모듈 및 데몬은 예를 들어 블루투스 장치를 사용할 때만 필요합니다. 또 다른 예는 ssh 데몬입니다. 이것은 inetd가 할 수있는 것입니다. 개인적으로 나는 이것이 필요할 때 대기 시간을 의미하기 때문에 이것을 좋아하는지 확신하지 못합니다 .ssh의 경우 내 inetd가 전체 시스템에 손상을 입히면 보안 취약점이 발생할 수 있다고 생각합니다. 그러나이 시스템을 사용하여이 시스템을 위반하는 것은 불가능하며 원하는 경우 서비스별로 또는 다른 방법으로이 기능을 비활성화 할 수 있다는 알림을 받았습니다.

또 다른 특징은 정기적으로 예정된 간격 또는 특정 시간에 시간 이벤트를 기반으로 시작하는 기능이 될 것입니다. 이것은 현재 crond와 무엇 과 비슷합니다 atd. 내가 말했지만 사용자 "크론"을 지원하지 않습니다. 개인적으로 이것은 가장 무의미한 것 같습니다. 나는 이것이 다중 사용자 환경에서 일하지 않는 사람들이 작성 / 생각한 것으로 생각합니다. 루트로 실행하지 않는 한 시스템의 유일한 사용자 인 경우 cron 사용자에게는 많은 목적이 없습니다. 나는 매일 다중 사용자 시스템에서 작업하며 규칙은 항상 사용자로 사용자 스크립트를 실행합니다. 그러나 나는 그들이하는 예언을 가지고 있지 않을 수도 있으며, 달리 crond거나 달리지 못하도록 결코 그렇게 만들지 않을 것입니다 atd. 그래서 그것은 내가 생각하는 개발자 외에 다른 사람을 해치지 않습니다.

systemd의 가장 큰 단점은 일부 데몬을 최대한 활용하려면 수정해야한다는 것입니다. 그들은 지금 작동하지만 소켓 모델을 위해 특별히 작성된 경우 더 잘 작동합니다.

대부분의 경우 스타트 업에 대한 시스템 사용자의 문제는 이벤트 시스템이며, 그것이 의미가 없거나 불필요하다고 생각합니다. 아마도 그들의 말이 가장 좋을 것입니다.

또는 더 간단하게 말하면 : 사용자가 D-Bus를 방금 시작했다는 사실은 NetworkManager도 시작해야한다는 표시가 아닙니다 (그러나 이것이 Upstart가하는 일임). 반대로 사용자가 NetworkManager를 요청할 때 D-Bus도 시작해야한다는 것을 분명히 알 수 있습니다 (대부분의 사용자가 기대하는 것입니다).
좋은 초기화 시스템은 필요한 것만으로 시작해야합니다. 게 으르거나 병렬화되고 미리. 그러나 필요 이상으로 시작해서는 안되며, 특히 해당 서비스를 사용할 수있는 설치된 모든 것이 아닙니다.

내가 이미 말했듯이 이것은 systemd 발표 에서 훨씬 더 포괄적으로 논의 됩니다.


미안하지만 발표는 책과 같습니다. 여기에 더 많은 내용을 포함시키기 전에 읽고 읽어야합니다.
xenoterracide

2
이것이 @John의 대답보다 어떻게 낫습니까? 자리 표시 자입니까? H 온라인 의 프로모션 ?
tshepang

1
@tshepang 잘 그것은 실제로 시스템 d의 발표에 연결되며 h 온라인 물건에는 그 링크와 다른 흥미로운 링크가 있습니다. 오래 지루한 읽기입니다. 일단 이해 한 후에 더 추가 할 수도 있습니다. 이것은 간단한 주제가 아닙니다 . 내가 이것을 썼을 때 나는 당신이 나중에 빨리 읽기를 원할 것이라고 생각했다. 하지만 저를 자유롭게 개조하십시오. 확실히 @jsbillings 답변은 괜찮으며 지금까지 내 것보다 낫습니다. 그러나 발표 자체를 읽는 것만 큼 좋지는 않습니다
xenoterracide

@tshepang 나는 아마 내일, 침대 후에 더 많이 추가 할 것이다. h 온라인 자료는 단지 좋은 기자가되어 내 출처를 인용 한 것입니다.
xenoterracide

@tshepang. 내 답변을 업데이트했습니다. irc : //frenode.net/systemd의 도움이되는 사람들이 어떤 종류의 수정을 제안하지 않기로 결정하지 않는 한 확실히 끝났습니다.
xenoterracide

11

대부분의 사용자가 잊어 버린 것은 cgroup 의 프로세스 구성입니다 .

따라서 systemd가 어떤 일을 시작했다면,이 일을 자체 cgroup에 넣고 프로세스가 해당 cgroup을 이스케이프 처리 할 수단이 없습니다 (권한이 없음). 그 결과는 다음과 같습니다.

  • 많은 사용자가있는 대규모 시스템의 관리자는 악의적 인 사용자 / 프로세스를 식별하는 효율적이고 새로운 방법을 갖습니다.
  • CPU 스케줄링의 우선 순위는 "Wonder autocgroup patch"에 의해보다 잘 결정될 수 있습니다 .

8

첫 번째 설계 초안부터 시작하여 시스템 시작에 대한 세부적인 비평과 시작을 포함하여 기존 init 시스템에 대한 자세한 비평 및 systemd가 시스템 수정을 제안하는 방법에 대해 자세히 살펴 보려면 홈 페이지 로 이동 하십시오 . 시간이 지남에 따라 LWN에 출판에 관한 기사가 여러 개있었습니다 . 시스템 (또는 펄스 오디오)에 대한 언급은 끝없는 화염 전쟁을 일으킨다는 점에 유의하십시오.

IMVHO (그리고 Fedora 사용자로서) 나는 그것에 매우 만족합니다. 이 라인의 내용은 현재 Linux 시스템의 복잡성을 처리하기 위해 오랫동안 기한이 지났습니다. Fedora는 한동안 upstart를 사용했지만 대부분 변경되지 않은 init 스크립트를 실행하여 sysvinit을 대체 할 수있는 단계를 결코 벗어나지 않았습니다. 부팅 구성을 단순화한다는 약속은 다시 비용이 듭니다.상호 의존성을 수동으로 설정하면 작동하지 않습니다. 체계화 된 수치는 의존성 자체로 나옵니다 (또는 의존성에 관계없이 물건을 시작하도록 허용하면 스스로 분류합니다). 또 다른 큰 장점은 (혹은 심각한 단점이라고 말하면) Linux 관련 기능을 활용하는 데 도움이된다는 것입니다 (특히 cgroup은 데몬과 모든 하위 항목을 분리 할 수 ​​있으므로 모니터링, 리소스 제한 또는 종료가 쉽습니다). 그룹; 다른 많은 사람들이 있습니다).


3

업무 일지-Systemd는 파일 로깅과 관련하여 문자 그대로 WinSXS 폴더와 비슷하며 드라이브에서 계속 먹어 치우는 파일 크기를 수동으로 삭제하거나 줄이지 않으면 복사본의 사본을 만듭니다. 나는 그것을 부트 로더 쿠키라고 부른다.


잘못된. 그것들은 사본이 아니며 구성 가능한 제한이 있습니다 freedesktop.org/software/systemd/man/journald.conf.html
pal
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.