☰

시스템이 SysV, Upstart 또는 Systemd initsystem을 사용하는지 확인하는 방법

tag-icon • tag-icon linux systemd init upstart sysvinit
시스템이 SysV, Upstart 또는 Systemd initsystem을 사용하는지 확인하는 방법

어떤 initsystem이 사용되고 있는지 쉽게 알 수 있는 방법이 있습니까(예: 가장 가까운 시스템 Debian wheezy또는 Fedora시스템)? 나는 그것이 initsystem을 Fedora 21사용한다는 것을 알고 있지만 systemd그것에 대해 읽었고 모든 관련 스크립트/symlink 가 /etc/systemd/.Debian squeezeCentOS 6 or 7

그러한 initsystem을 검증하기 위해 어떤 기술이 존재합니까?

답변1

init 프로세스에는 항상 PID 1이 할당됩니다. /proc파일 시스템은 PID가 지정된 실행 파일의 경로를 얻는 방법을 제공합니다.

다시 말해서:

nathan@nathan-desktop:~$ sudo stat /proc/1/exe
  File: '/proc/1/exe' -> '/sbin/upstart'

보시다시피 내 Ubuntu 14.10 시스템의 init 프로세스는 Upstart입니다. Ubuntu 15.04는 systemd를 사용하므로 이 명령을 실행하면 다음이 생성됩니다.

nathan@nathan-gnome:~$ sudo stat /proc/1/exe
  File: '/proc/1/exe' -> '/lib/systemd/systemd'

시스템에서 /sbin/init결과가 나오면 파일 수를 세어보세요.

nathan@nathan-gnome:~$ sudo stat /proc/1/exe
  File: '/proc/1/exe' -> '/sbin/init'
nathan@nathan-gnome:~$ stat /sbin/init
  File: ‘/sbin/init’ -> ‘/lib/systemd/systemd’

또한 이를 실행하여 자세히 알아볼 수도 있습니다.

[user@centos ~]$ /sbin/init --version
init (upstart 0.6.5)
Copyright (C) 2010 Canonical Ltd.

답변2

시스템을 탐색하여 지표를 찾을 수 있습니다. 한 가지 방법은 세 개의 디렉터리가 있는지 확인하는 것입니다.

  • /usr/lib/systemdsystemd 기반 시스템을 사용하고 있음을 알려줍니다.

  • /usr/share/upstartUpstart 기반 시스템을 사용하고 있음을 나타내는 좋은 지표입니다.

  • /etc/init.d상자의 기록에 SysV init가 있음을 알려줍니다.

문제는 이것이 휴리스틱이므로 특정 측정항목을 별도로 고려하기보다는 다른 데이터와 함께 고려해야 한다는 것입니다. 지금 보고 있는 Ubuntu 14.10 상자에는 세 개의 디렉터리가 모두 포함되어 있습니다. 왜? Ubuntu는 이 버전에서 방금 Upstart에서 systemd로 전환했지만 이전 버전과의 호환성을 위해 Upstart 및 SysV init를 유지하기 때문입니다.

결국 가장 좋은 답은 '경험'이라고 생각합니다. CentOS 7 시스템에 로그인되어 있고 시스템화되어 있음을 알 수 있습니다. 이것을 어떻게 배우나요? 재생, RTFMing 등 모든 경험치는 같은 방식으로 획득됩니다.

나는 이것이 매우 만족스러운 대답이 아니라는 것을 알고 있지만 시장이 분열되고 비표준적인 디자인을 생산할 때 일어나는 일입니다. 이는 컬러 출력을 ls허용 -C할지 여부를 어떻게 알 수 있는지 묻는 것과 같습니다 . --color역시 답은 '경험'이다.

답변3

사실 이것은 꽤 어려운 질문이다. 가장 큰 어려움 중 하나는 사람들이 이 작업을 수행하고 싶어하는 가장 일반적인 장소가 사람들이 물건을 설치하거나 변경할 가능성이 가장 높은 장소라는 것입니다. 또 하나는 미묘하지만 매우 중요한 차이가 있다는 것입니다.설치된 시스템 관리 도구 세트,현재 실행 중인 시스템 관리 도구 세트, 그리고다음 부팅 시 실행될 시스템 관리 도구 세트.

물론 패키지 관리자를 사용하여 설치할 항목을 결정할 수 있습니다. 하지만 여러 시스템을 나란히 설치할 수 있기 때문에 상황이 복잡해집니다.

예를 들어 Debian Linux에서는 다음을 설치할 수 있습니다.체계패키지로 제공되지만 별도로 설치됨systemd-sysv활성 시스템용 패키지로 만듭니다. 그 목적이 체계화되어 있으며,시스템 베넷패키지를 동시에 설치할 수 있습니다. 실제로 Debian Linux 커뮤니티는 이미 Debian 8에서 다른 이름( /lib/sysvinit/init, /lib/systemd/systemd, /sbin/runit-init, /sbin/minit, /sbin/system-manager등)을 가진 각 프로그램으로 이동하는 조치를 취했으며 이러한 이유로 "비활성" 패키지는 Debian 8에서 충돌하지 않습니다. 이름 /sbin/init. /sbin/init그런 다음 다음 부팅 시 실행되도록 "활성화 패키지"를 통해 구성된 항목에 대한 심볼릭 링크가 있습니다.

현재 실행 중인 항목을 결정하고 다음 프로그램 실행을 준비하는 것은 다양한 수준의 오탐 위험과 다양한 수준의 문서화를 통해 일련의 도구 세트별 테스트를 통해서만 수행할 수 있습니다. 구체적으로 현재 어떤 System Manager가 실행되고 있는지 확인하려면 프로세스 목록이나 System Manager가 게시한 다양한 API를 살펴봐야 합니다. 그러나 함정이 전혀 없는 것은 아닙니다.

일반적으로 구매하지 않음

확실히 일어날 일부터 시작하자아니요일하다.

  • /proc/1/exe/sbin/initupstart 또는 시스템 5가 init실행 중일 때 동일한 콘텐츠를 가리킵니다. 일부 시스템에서는 /sbin/initsystemd가 실행 중일 때도 마찬가지입니다 .

    앞서 언급했듯이 Debian Linux 군중은 모든 프로그램이 다른 이름을 갖기를 원합니다. 하지만 이것은 데비안에만 국한된 것입니다.멀리일반에서 왔으며 프로그램이 호출될 때 /sbin/init실제로 도움이 되지 않습니다 (부트로더의 initramfs 단계를 통해). Felix von Leitner의 minit만이 실제로 데비안 8에 패키지되어 있으며 자체 이름으로 호출됩니다.

  • 제어 API 파일의 존재는 /dev/initctlSystem 5에만 국한되지 않습니다 init. systemd systemd-initctl에는 이 서비스를 제공하는 (프로세스 #1이 아닌) 서버가 있습니다 . 요아킴 닐센의finit서빙도 해보세요. (더 흥미롭게 만들기 위해 데비안에는 이제 /run/initctl.https://superuser.com/a/888936/38062더 알아보기. )
  • systemd, upstart, System 5 rc및 OpenRC는 /etc/init.d/처음 두 가지의 경우 이전 버전과의 호환성을 위해 모든 프로세스를 수행합니다. 그 존재가 특정 시스템의 존재를 나타내지는 않습니다.

탐지 시스템 5init

아이러니하게도 설명대로https://unix.stackexchange.com/a/196197/5132, 일방 통행적어도 데비안 리눅스에서는시스템 5의 존재 여부를 탐지하기 위한 조건 init은 존재 여부이다 /etc/inittab. 하지만:

  • 와 같은 데비안 패키지입니다 /etc/inittab.
  • 전체 문제의 일부는 /etc/inittab시스템 5를 사용하는 경우에도 이 문제가 여전히 존재한다는 것입니다.init과거 어느 때라도, 패키지를 제거해도 해당 구성 파일은 삭제되지 않기 때문입니다. (Debian 7의 여러 패키지가 /etc/inittab.
  • 이것은 역방향 테스트입니다.

탐지 시스템

"공식적인" 방식으로 실행 중인 시스템 관리자로 systemd를 확인하려면 /run/systemd/system시작 시 systemd 자체에 의해 생성된 디렉터리이며 /run.

하지만 이것은 단지너무 가능하지 않음. 이 수표는상했다, 왜냐하면 그건 소용 없어이 디렉터리도 생성합니다.

다른 비공식 검사는 작동하지 않습니다.

  • systemd는 버전 이름과 버전 번호도 포함하는 D-Bus를 통해 완전한 RPC API를 게시합니다.
  • /run/systemd/private동일한 것이 존재한다고 보장할 수 없으며, 동일한 것이 쓸데없이 반복될 수 있습니다.

nosh 감지

system-manager~에간식디렉터리 를 만듭니다 /run/system-manager. 그러나 이것은 또한 시스템 검사와 동일한 약점을 가지고 있습니다.

기타 비스타터:

  • nosh 의 디자인은 system-manager파일 시스템에 파이프나 소켓을 생성하지 않으며 처음부터 RPC API도 없습니다.
  • nosh는 service-manager일반적으로 에 API 소켓이 있지만 /run/service-manager/controlnosh를 실행할 수도 있습니다.제공하다다른 시스템 관리자 아래의 관리자이므로 사람들에게 아무 것도 알려주지 않습니다.체계관리자는 프로세스 #1로 실행됩니다. 그러나 이름 자체를 설정하지는 않습니다.
  • system-control versionsystemctl versionnosh (systemd 호환성 심이 설치된 경우) 및 initctl version(upstart 호환성 심이 설치된 경우) 에서 내보낸 버전 문자열은 도구 세트의 존재만을 나타냅니다. 이러한 도구는 실행 중인 시스템을 쿼리하지 않기 때문입니다.

신생 기업 감지

Upstart 자체는 initctlD-Bus를 통해 API 호출을 수행하며 공식 확인은 실행 가능한지 initctl, 출력 어딘가에 "upstart" 문자열이 포함되어 있는지 확인하는 것입니다.

그러나 systemd API와 마찬가지로:

  • API가 내일 사용 가능하거나 마음대로 변경되지 않을 것이라는 보장은 없습니다.
  • 특정 호환성 필러가 존재하지 않거나 앞으로도 존재하지 않을 것이라는 보장은 없습니다.

    실제로 호환 스페이서가 이미 존재합니다. nosh 에는 upstart initctl, start및 명령에 대한 shim을 제공하는 upstart 호환성 패키지가 있습니다. 다행스럽게도(의도적이긴 하지만) 개스킷에서 "upstart"라는 소리가 나지 않습니다.stopstatusinitctl

    루트 ~ #initctl 버전
Nosh 버전 1.14
루트~#

답변4

프로그램에서 이에 대해 정의된 API를 사용할 수도 있습니다. Systemd에는 실행 중인 systemd 인스턴스에 성공적으로 연결할 수 있는지 확인하는 libsystemd가 함께 제공됩니다.

관련 정보