Czy systemd nadal ma koncepcję poziomów pracy? Na przykład, czy nie ma sensu używać telinit <number>?

SystemD Run-Level Low-Down

W SystemD (aemon) poziomy uruchamiania są widoczne jako „Cele”. Koncepcja wciąż istnieje, ale przepływ pracy w celu uzyskania pożądanego rezultatu dla twoich wymagań jest inny.

W załączeniu należy wyjaśnić tę kwestię.

Jak zmienić bieżący poziom działania?

$ systemctl isolate runlevelX.target

Jak zmienić domyślny poziom uruchamiania dla następnego rozruchu?

# Create a symlink
$ ln -sf /usr/lib/systemd/system/multi-user.target /etc/systemd/system/default.target

• ln -sf TARGET DESTINATION
• -s tworzy dowiązanie symboliczne
• -f usuwa istniejący plik docelowy

LUB (jak sugeruje @centimane) po prostu użyj polecenia „błogosławiony” systemd:

systemctl set-default [target name].target

Jak zidentyfikować bieżący poziom działania?

$ systemctl list-units --type=target

Nie. Jak sami ludzie systemowi napisali dwa razy, raz w telinitpodręczniku i raz w runlevelpodręczniku, poziomy uruchamiania są „przestarzałe”. Możesz zapomnieć o poziomach pracy.

Te rzeczy w ogóle nie istnieją w systemie, bez kilku podkładek kompatybilności.

• Istnieje kilka dowiązań symbolicznych dla nazw celów, ale cele te nigdy nie są właściwie używane przez systemd.
  • Raczej proces ładowania początkowego wykorzystuje default.target(a stąd jeden lub oba z a graphical.targeti a multi-user.target), a rescue.targetlub an emergency.target. A proces zamykania obejmuje a shutdown.target, a reboot.target, a halt.targetlub a poweroff.target. Żadne cele docelowe nie są zaangażowane ani w bootstrap, ani w zamknięcie.
  • telinitPoleceń, które można by pomyśleć korzysta z kompatybilnością symboliczne linki do mapy swoje argumenty wiersza poleceń, nie robi albo. Jest przewodowych tabeli w kodzie źródłowym telinitprogramu, a numery 2, 3, 4, i 5jako argumenty polecenia były włączone do mapowania multi-user.targeti graphical.target.
  • systemd-update-utmp ma również wewnętrzny stolik przewodowy.
• Nie ma „tabeli inicjacji” elementów poziomu pracy. Systemd jest kompatybilny tylko z van Smoorenburg rc, a nie z van Smoorenburg init.
• Sam systemd nie utrzymuje wartości „bieżącego poziomu pracy”. Przeciwnie, niemal całkowicie nieudokumentowana systemd-update-utmpkomenda działa wewnętrznie pod względem aktywacji Zjednoczone rescue.target, multi-user.targetoraz graphical.target.
• systemd-sysv-generator, systemd generator jednostek usług kompatybilności wstecznej, łączy /etc/rc[234].dkatalogi w jedną Wanted-Byrelację do multi-user.targetgenerowanych jednostek usług. Brak rzeczywistego odniesienia do poziomów uruchamiania w wygenerowanych jednostkach serwisowych. (Kiedyś, dawno temu, ale usystematyzowani ludzie stwierdzili, że to poszło nie tak, ponieważ nie było ich nigdzie indziej.)

Jeśli ktoś jest użytkownikiem systemu, który buduje systemd, podobnie jak Arch Linux dla pytającego w „ Dlaczego„ init 0 ”powoduje„ Nadmiar argumentów ”podczas instalacji Arch? ”, To nawet nie dostaje podkładek kompatybilności i takie polecenia w init 0wyniku „systemowego” zachowania systemowego, które polega na narzekaniu, że polecenie zostało niepoprawnie wywołane.

Dalsza lektura

• Lennart Poettering i in runlevel. systemowe strony podręcznika. Freedesktop.org.
• Lennart Poettering i in telinit. systemowe strony podręcznika. Freedesktop.org.
• Lennart Poettering i in bootup. systemowe strony podręcznika. Freedesktop.org.
• Lennart Poettering (2015-02-08). wszędzie: usuń konfigurowalność poziomu uruchamiania sysv do mapowania docelowego . systemd. github.
• /unix//a/196014/5132
• /unix//a/196197/5132
• /unix//a/233581/5132
• /unix//a/211927/5132
• /unix//a/392612/5132
• Jonathan de Boyne Pollard (2015). /etc/inittabnależy już do przeszłości. . Często udzielane odpowiedzi.

Dziękuję bardzo. Więc jeśli dobrze zrozumiałem:

Na przykład:

ls -ll /usr/lib/systemd/system/runlevel*.target

Wynik:

/usr/lib/systemd/system/runlevel0.target -> poweroff.target
/usr/lib/systemd/system/runlevel1.target -> rescue.target
/usr/lib/systemd/system/runlevel2.target -> multi-user.target
/usr/lib/systemd/system/runlevel3.target -> multi-user.target
/usr/lib/systemd/system/runlevel4.target -> multi-user.target
/usr/lib/systemd/system/runlevel5.target -> graphical.target
/usr/lib/systemd/system/runlevel6.target -> reboot.target

Jak widać, koncepcja poziomów działania istnieje, ale jest dość przestarzała, ponieważ pliki runlevel.target nie są tak naprawdę „prawdziwymi” plikami, ale miękkimi linkami do nowego, nowoczesnego, lepiej nazwanego schematu plików, który systemd lubi nazywać je „celami”.

Więc jeśli chciałbyś zrobić coś takiego, telinit 5to byłoby tak: systemctl isolate runlevel5.target co jest identyczne z: systemctl isolate graphical.target(moim zdaniem zalecane).

Na wypadek, gdybyś był zainteresowany wszystkimi możliwymi celami:

ls /usr/lib/systemd/system/*.target

Systemd wprowadzono cele jako odpowiednik dla poziomów pracy w init sysv. programiści sytemd sprawili, że jest prawie kompatybilny z większością skryptów sysV. To samo dzieje się z telinit <runlevel>. Przekłada się to na odpowiednik systemowy.

Na przykład telinit 0wyłącza maszynę. systemd ma poweroff.target, aby zrobić to samo co poziom pracy 0 . Tak telinit 0jest tłumaczone przez systemd, aby aktywować poweroff.target .

Ale istnieją pewne problemy ze zgodnością w systemach inicjujących sytemd i sysV-> https://www.freedesktop.org/wiki/Software/systemd/Incompatabilities .