Wykryj system init za pomocą powłoki

Może to mieć więcej wspólnego z wykrywaniem systemów operacyjnych, ale szczególnie potrzebuję obecnie używanego systemu init.

Fedora 15 i Ubuntu używają teraz systemd, Ubuntu używa Upstart (domyślnie długi czas do 15.04), podczas gdy inne używają odmian Systemu V.

Mam aplikację, którą piszę, aby być demonem międzyplatformowym. Skrypty inicjujące są generowane dynamicznie na podstawie parametrów, które można przekazać podczas konfiguracji.

To, co chciałbym zrobić, to wygenerowanie skryptu tylko dla konkretnego systemu init, którego używają. W ten sposób skrypt instalacyjny może być uruchamiany rozsądnie bez parametrów jako root, a demon może być „zainstalowany” automatycznie.

Oto co wymyśliłem:

• Wyszukaj systemd, upstart itp w / bin
• Porównaj / proc / 1 / comm z systemd, upstart itp
• Zapytaj użytkownika

Jaki byłby najlepszy sposób, aby to zrobić na wiele platform / platform?

Rodzaj pokrewnych. Czy mogę polegać na bash, aby być na większości * nix, czy jest to zależne od dystrybucji / systemu operacyjnego?

Platformy docelowe:

• System operacyjny Mac
• Linux (wszystkie dystrybucje)
• BSD (wszystkie wersje)
• Solaris, Minix i inne * nix

Na drugie pytanie odpowiedź brzmi „ nie” i powinieneś rzucić okiem na zasoby dotyczące programowania przenośnych powłok .

Jeśli chodzi o pierwszą część - po pierwsze, z pewnością musisz być ostrożny. Powiedziałbym, aby wykonać kilka testów, aby się upewnić - ponieważ fakt, że ktoś ma zainstalowany systemd (np.), Nie oznacza, że ​​jest on faktycznie używany jako domyślny init. Również patrzenie na to /proc/1/commmoże być mylące, ponieważ niektóre instalacje różnych programów inicjujących mogą automatycznie utworzyć /sbin/initdowiązanie symboliczne lub nawet zmienić nazwę swojego głównego programu.

Być może najbardziej użyteczną rzeczą może być przyjrzenie się typowi skryptów inicjujących - ponieważ są one tym, co faktycznie stworzysz, bez względu na to, co je uruchamia.

Na marginesie, możesz również przyjrzeć się OpenRC, który ma na celu zapewnienie struktury skryptów init, która jest kompatybilna zarówno z systemami Linux, jak i BSD.

Sam doszedłem do tego problemu i postanowiłem zrobić kilka testów. W pełni zgadzam się z odpowiedzią, że dla każdej dystrybucji należy spakować osobno, ale czasami istnieją praktyczne problemy, które temu zapobiegają (zwłaszcza siła robocza).

Dla tych, którzy chcą „automatycznie wykryć”, oto, co odkryłem na ograniczonym zestawie dystrybucji (więcej poniżej):

• Możesz powiedzieć upstart od:

  [[ `/sbin/init --version` =~ upstart ]] && echo yes || echo no

• Możesz powiedzieć systemd z:

  [[ `systemctl` =~ -\.mount ]] && echo yes || echo no

• Możesz powiedzieć sys-v init z:

  [[ -f /etc/init.d/cron && ! -h /etc/init.d/cron ]] && echo yes

Oto moje eksperymenty z następującą linią poleceń:

if [[ `/sbin/init --version` =~ upstart ]]; then echo using upstart;
elif [[ `systemctl` =~ -\.mount ]]; then echo using systemd;
elif [[ -f /etc/init.d/cron && ! -h /etc/init.d/cron ]]; then echo using sysv-init;
else echo cannot tell; fi

w instancjach ec2 (podaję identyfikator AMI dla US-east):

• ArchLinux: używa systemd (od 2012.10.06 )
• CentOS6.4 ami-52009e3b: using upstart
• CentOS7 ami-96a818fe: using systemd
• Debian 6 ami-80e915e9: przy użyciu sysv-init
• Debian 7.5 ami-2c886c44: przy użyciu sysv-init
• Debian 7.6 GCE container-vm: using sysv-init
• RHEL 6.5 ami-8d756fe4: przy użyciu upstart
• SLES 11 ami-e8084981: using sysv-init
• Ubuntu 10.04 ami-6b350a02: przy użyciu aktualizacji początkowej
• Ubuntu 12.04 ami-b08b6cd8: using upstart
• Ubuntu 14.04 ami-a427efcc: using upstart
• Ubuntu 14.10 i nowsze: za pomocą systemd
• AWS linux 2014.3.2 ami-7c807d14: przy użyciu upstart
• Fedora 19 ami-f525389c: przy użyciu systemd
• Fedora 20 ami-21362b48: przy użyciu systemd

Żeby było jasne: nie twierdzę, że jest to niezawodne! , prawie na pewno nie jest. Zauważ też, że dla wygody używam dopasowań regularnych bash, które nie są dostępne wszędzie. Powyższe jest dla mnie wystarczająco dobre. Jeśli jednak znajdziesz dystrybucję, w której się nie powiedzie, daj mi znać, a ja postaram się to naprawić, jeśli istnieje EC2 AMI, który odtwarza problem ...

Korzystanie z procesów

Patrząc na wynik kilku pspoleceń, które mogą wykryć różne wersje systemd& upstart, które można by spreparować w następujący sposób:

dorobkiewicz

$ ps -eaf|grep '[u]pstart'
root       492     1  0 Jan02 ?        00:00:00 upstart-udev-bridge --daemon
root      1027     1  0 Jan02 ?        00:00:00 upstart-socket-bridge --daemon

systemd

$ ps -eaf|grep '[s]ystemd'
root         1     0  0 07:27 ?        00:00:03 /usr/lib/systemd/systemd --switched-root --system --deserialize 20
root       343     1  0 07:28 ?        00:00:03 /usr/lib/systemd/systemd-journald
root       367     1  0 07:28 ?        00:00:00 /usr/lib/systemd/systemd-udevd
root       607     1  0 07:28 ?        00:00:00 /usr/lib/systemd/systemd-logind
dbus       615     1  0 07:28 ?        00:00:13 /bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation

Zwrócenie uwagi na nazwę procesu, jakim jest PID # 1, może również potencjalnie rzucić światło na to, który system inicjujący jest używany. Na Fedorze 19 (która wykorzystuje systemdna przykład:

UID        PID  PPID  C STIME TTY          TIME CMD
root         1     0  0 07:27 ?        00:00:03 /usr/lib/systemd/systemd --switched-root --system --deserialize 20

Zauważ, że to nie jest init. Na Ubuntu z Upstart jest nadal /sbin/init.

$ ps -efa|grep init
root         1     0  0 Jan02 ?        00:00:03 /sbin/init

UWAGA: Należy jednak zachować ostrożność. Nie ma w tym nic, co mówi, że określony system inicjujący używany w danej dystrybucji musi mieć systemdPID # 1.

rodzajowy

$ (ps -eo "ppid,args" 2>/dev/null || echo "ps call error") \
    | awk 'NR==1 || $1==1' | less
 PPID   COMMAND
    1   /lib/systemd/systemd-journald
    1   /lib/systemd/systemd-udevd
    1   /lib/systemd/systemd-timesyncd

Spójrz na procesy z ppid 1 (potomkami procesu init). (Niektóre) nazwy procesów potomnych mogą wskazywać na używany system init.

System plików

Jeśli przesłuchasz initplik wykonywalny, możesz również uzyskać z niego trochę informacji. Po prostu parsuje --versionwyjście. Na przykład:

dorobkiewicz

$ sudo /sbin/init --version
init (upstart 1.5)
Copyright (C) 2012 Scott James Remnant, Canonical Ltd.

This is free software; see the source for copying conditions.  There is NO warranty; not even for MERCHANTABILITY
or FITNESS FOR A PARTICULAR PURPOSE.

systemd

$ type init
init is /usr/sbin/init

UWAGA: Fakt, że initnie znajduje się w standardowej lokalizacji, jest trochę podpowiedź / powiedzieć. Zawsze znajduje się w /sbin/initsystemach sysvinit.

sysvinit

$ type init
init is /sbin/init

Także to:

$ sudo init --version
init: invalid option -- -
Usage: init 0123456SsQqAaBbCcUu

Wnioski

Wydaje się więc, że nie ma jednego sposobu, aby to zrobić, ale możesz sformułować zestaw testów, które pozwoliłyby określić, z którego systemu init korzystasz z dość wysokim poziomem pewności.

Nie tak wydajne, ale wydaje mi się, że działa.

strings /sbin/init | grep -q "/lib/systemd" && echo SYSTEMD
strings /sbin/init | grep -q "sysvinit" && echo SYSVINIT
strings /sbin/init | grep -q "upstart" && echo UPSTART

Wydrukuje więcej wierszy, jeśli pasuje więcej niż jeden ciąg, co można przetłumaczyć na „Nie mogę zgadnąć”. Ciągi używane w grep mogą być nieznacznie modyfikowane, ale podczas testowania w następnym systemie zawsze otrzymałem jedną linię.

• RHEL 6.4 [UPSTART]
• RHEL ES 4 (Nahant Update 7) [SYSVINIT]
• Ubuntu 16.04.1 LTS [SYSTEMD]
• Ubuntu 14.04.2 LTS [UPSTART]
• Fedora wydanie 23 (powłoka online) [SYSTEMD]
• Debian GNU / Linux 7 (powłoka online) [SYSTEMD]

Bardziej uproszczone podejście do tego samego rozwiązania (ale zatrzymuje się przy pierwszym meczu)

strings /sbin/init |
  awk 'match($0, /(upstart|systemd|sysvinit)/) { print toupper(substr($0, RSTART, RLENGTH));exit; }'

Czasami jest to tak proste, jak użycie ls :

$ ls -l /sbin/init
lrwxrwxrwx 1 root root 20 juin  25 12:04 /sbin/init -> /lib/systemd/systemd

Myślę, że jeśli /sbin/initnie jest to symboliczny link, będziesz musiał sprawdzić dalsze poniższe sugestie w innych odpowiedziach.

1. Do tego służą pakiety specyficzne dla dystrybucji. Prawidłowe instalowanie oprogramowania to znacznie więcej niż wykrywanie systemu init. Wiele dystrybucji używa SysVinit, ale nie wszystkie piszą swoje skrypty inicjujące w ten sam sposób. Właściwym sposobem rozwiązania tego jest uwzględnienie wszystkich różnych wariantów, a następnie spakowanie go przy użyciu plików spec z nazwami zależności specyficznymi dla dystrybucji dla dystrybucji rpm, plików deb dla systemów opartych na apt itp. Prawie wszystkie dystrybucje mają jakąś specyfikację pakietu umie pisać, które zawierają zależności, skrypty, skrypty inicjujące itp. Nie wymyślaj tutaj koła na nowo.

2. Nie. Co sprowadza nas z powrotem do 1. Jeśli potrzebujesz bash, powinna to być zależność. Możesz określić tę kontrolę w ramach skryptów konfiguracyjnych, ale powinna ona również znajdować się w opisach pakietów.

Edycja: użyj flag na skrypcie konfiguracyjnym, takim jak --with upstartlub --without sysvinit. Wybierz rozsądne ustawienie domyślne, a następnie skrypty, które pakują twoje oprogramowanie dla innych dystrybucji, mogą uruchomić to z innymi opcjami.

Na Gentoo spójrz na pid 1:

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.0  0.0   4216   340 ?        Ss    2013   0:57 init [3]

Jeśli tak init, to system inicjujący to OpenRC. Jeśli tak systemd, to system inicjujący to systemd.

Możesz wykryć Gentoo za pomocą [ -f /etc/gentoo-release ].

Inną metodą Gentoo jest użycie profile-config show, która pokaże, jaki domyślny profil jest używany. Wszystkie profile oprócz dwóch kończących się na / systemd używają init OpenRC. Należy pamiętać, że są one reprezentatywne tylko dla wartości domyślnych i możliwe jest, że użytkownik podjął kroki w celu zastąpienia tej wartości domyślnej i może nie wskazywać na faktyczne użycie menedżera init.

Na debian / sbin / init znajduje się dowiązanie symboliczne do twojego domyślnego init

ls -l /sbin/init

poda informacje, których szukasz.

$ ls -l /sbin/init 
lrwxrwxrwx 1 root root 20 nov 18 13:15 /sbin/init -> /lib/systemd/systemd

Samo włączenie się w proces z PID 1 powie ci:

strings /proc/1/exe |grep -q sysvinit
strings /proc/1/exe |grep -q systemd

Pomocne może być również sprawdzenie deskryptorów plików. I pochodzi z faktycznego uruchomienia init (obecnie Debian pozwala na zainstalowanie większej liczby systemów init) :-)

$ ls -l /proc/1/fd |grep systemd
lrwx------ 1 root root 64 srp 14 13:56 25 -> /run/systemd/initctl/fifo
lr-x------ 1 root root 64 srp 14 13:56 6 -> /sys/fs/cgroup/systemd

$ ls -l /proc/1/fd |grep /run/initctl # sysvinit
lrwx------ 1 root root 64 srp 14 14:04 10 -> /run/initctl

$ ls -l /proc/1/fd |grep upstart
l-wx------ 1 root root 64 srp 13 16:09 13 -> /var/log/upstart/mysql.log.1 (delete
l-wx------ 1 root root 64 srp 13 16:09 9 -> /var/log/upstart/dbus.log.1 (deleted)

$ ls -l /proc/1/fd # busybox
total 0
lrwx------    1 root     root          64 Jan  1 00:00 0 -> /dev/console
lrwx------    1 root     root          64 Jan  1 00:00 1 -> /dev/console
lrwx------    1 root     root          64 Jan  1 00:00 2 -> /dev/console

Prawdopodobnie bezpieczniejszym sposobem na sprawdzenie zajętości jest check /proc/1/exe, ponieważ zajęty zwykle używa dowiązań symbolicznych:

$ ls -l /proc/1/exe 
lrwxrwxrwx    1 root     root          0 Jan  1 00:00 /proc/1/exe -> /bin/busybox

Więc sprawdź może być:

{ ls -l /proc/1/fd |grep -q systemd && echo "init: systemd"; } || \
{ ls -l /proc/1/fd |grep -q /run/initctl && echo "init: sysvinit"; } || \
{ ls -l /proc/1/fd |grep -q upstart && echo "init: upstart"; } || \
{ ls -l /proc/1/exe |grep -q busybox && echo "init: busybox"; } || \
echo "unknown init"

Nie wiem o innych systemach niż Debian (wheezy) / lub Ubuntu (14.10.), Ale takie problemy testuję zwykłym starym filepoleceniem.

file /sbin/init

daj to:

/sbin/init: symbolic link to 'upstart'

Systemy Debian z systemd(np. Sid) pokazują to:

# file /sbin/init 
/sbin/init: symbolic link to /lib/systemd/systemd

Miałem również ten sam problem i wykonałem wiele testów na niektórych maszynach RedHat / CentOS / Debian / Ubuntu / Mint. Właśnie z tym skończyłem, z dobrymi wynikami.

1. Znajdź nazwę pliku wykonywalnego za pomocą PID 1:

   ps -p 1

   Jeśli jest to systemd lub Upstart, problem został rozwiązany. Jeśli jest to „init”, może to być dowiązanie symboliczne lub coś innego niż nazwa początkowa. Śmiało.

2. Znajdź prawdziwą ścieżkę do pliku wykonywalnego (działa tylko jako root):

   ls -l `which init`

   Jeśli initjest dowiązaniem symbolicznym do Upstart lub systemd, problem został rozwiązany. W przeciwnym razie jest prawie pewne, że masz init SysV. Ale może to być źle nazwany plik wykonywalny. Śmiało.

3. Znajdź pakiet, który udostępnia plik wykonywalny. Niestety jest to zależne od dystrybucji:

   dpkg-query -S (executable real path) # Debian  
   rpm -qf (executable real path) # RedHat  

Następnie, jeśli chcesz napisać skrypt (najśmieszniejsza część, IMHO), to są moje jednowierszowe (uruchamiane jako root):

ls -l $(which $(ps -p 1 o comm)) | awk '{ system("dpkg-query -S "$NF) }' # Debian  

ls -l $(which $(ps -p 1 o comm)) | awk '{ system("rpm -qf "$NF) }' # RedHat  

To jest naprawdę łatwe dla niektórych systemów init. Dla systemd:

test -d /run/systemd/system

dla upstart:

initctl --version | grep -q upstart

cokolwiek innego, możesz po prostu założyć na podstawie dystrybucji (uruchomionej na OS X, sysvinit na Debianie, OpenRC na Gentoo).

Oto skrypt bash do wykrycia. W tej chwili sprawdza tylko dostępność i system, ale powinna być łatwa do rozszerzenia. Wziąłem to z kodu, który włączyłem do skryptu instalacyjnego sterownika DisplayLink .

detect_distro()
{
  # init process is pid 1
  INIT=`ls -l /proc/1/exe`
  if [[ $INIT == *"upstart"* ]]; then
    SYSTEMINITDAEMON=upstart
  elif [[ $INIT == *"systemd"* ]]; then
    SYSTEMINITDAEMON=systemd
  elif [[ $INIT == *"/sbin/init"* ]]; then
    INIT=`/sbin/init --version`
    if [[ $INIT == *"upstart"* ]]; then
      SYSTEMINITDAEMON=upstart
    elif [[ $INIT == *"systemd"* ]]; then
      SYSTEMINITDAEMON=systemd
    fi
  fi

  if [ -z "$SYSTEMINITDAEMON" ]; then
    echo "WARNING: Unknown distribution, assuming defaults - this may fail." >&2
  else
    echo "Init system discovered: $SYSTEMINITDAEMON"
  fi
}

Istnieje wiele problemów związanych z kompatybilnością podczas testowania systemd vs initd. To faktycznie działa na OpenSuSE 42.1:ps --pid 1 | grep -q systemd && echo 'systemd' || echo 'init'

Dla systemd:

if [[ `systemctl is-system-running` =~ running ]]; then echo using systemd; fi

Moje rozwiązanie: sprawdź polecenie uruchomione jako proces o identyfikatorze 1.

case `cat /proc/1/comm` in
    init)    echo Init ;;
    systemd) echo SystemD ;;
    # add here other patterns
    *)       echo "unknown: '`cat /proc/1/comm`'" ;;
esac

W tej chwili mam dostęp tylko do maszyn Init i SystemD, więc nie mogę powiedzieć, jak zostanie wykryty Upstart lub macOS (OS X), ale będę szukał dalej.

check(){
    if hash systemctl 2>/dev/null;
    then
        echo "there is systemd"
    fi

    if hash initctl 2>/dev/null;
    then
        echo "there is upStart"
    fi

    if [ -f "/etc/inittab"];
    then
        echo "there is systemV"
    fi
}