systemd - Online sa Cloud

PROGRAMA:

NAME

systemd, init - systemd system at service manager

SINOPSIS

systemd [OPSYON...]

sa loob [OPSYON...] {COMMAND}

DESCRIPTION

Ang systemd ay isang system at service manager para sa mga operating system ng Linux. Kapag tumakbo bilang una
proseso sa boot (bilang PID 1), ito ay gumaganap bilang init system na nagdadala at nagpapanatili ng userspace
mga serbisyo.

Para sa pagiging tugma sa SysV, kung ang systemd ay tinatawag bilang sa loob at isang PID na hindi 1, gagawin nito
isakatuparan telini at ipasa ang lahat ng argumento ng command line na hindi nabago. Ibig sabihin sa loob at
telini ay halos katumbas kapag na-invoke mula sa mga normal na session sa pag-log in. Tingnan mo telini(8) para sa
karagdagang informasiyon.

Kapag tumakbo bilang isang instance ng system, binibigyang-kahulugan ng systemd ang configuration file system.conf at
ang mga file sa system.conf.d na mga direktoryo; kapag tumakbo bilang isang halimbawa ng gumagamit, ang systemd ay nagbibigay-kahulugan
ang configuration file na user.conf at ang mga file sa user.conf.d na mga direktoryo. Tingnan mo systemd-
sistema.conf(5) para sa karagdagang impormasyon.

Opsyon

Ang mga sumusunod na opsyon ay nauunawaan:

--pagsusulit
Tukuyin ang pagkakasunud-sunod ng pagsisimula, itapon ito at lumabas. Ito ay isang opsyon na kapaki-pakinabang para sa pag-debug
lamang.

--dump-configuration-item
Itapon ang nauunawaang mga item sa configuration ng unit. Naglalabas ito ng maikli ngunit kumpletong listahan ng
naiintindihan ang mga item sa pagsasaayos sa mga file ng kahulugan ng unit.

--unit=
Itakda ang default na unit na i-activate sa startup. Kung hindi tinukoy, nagde-default sa default.target.

--sistema, --gumagamit
para --sistema, sabihin sa systemd na magpatakbo ng isang instance ng system, kahit na ang process ID ay hindi 1,
ie systemd ay hindi tumatakbo bilang init na proseso. --gumagamit ginagawa ang kabaligtaran, nagpapatakbo ng isang user
instance kahit na ang process ID ay 1. Normally, hindi na dapat kailangan pang pumasa
ang mga opsyong ito, dahil awtomatikong nakikita ng systemd ang mode kung saan ito sinimulan. Ang mga ito
ang mga opsyon ay kaya hindi gaanong ginagamit maliban sa pag-debug. Tandaan na hindi ito suportado
booting at pagpapanatili ng isang buong system na may systemd na tumatakbo --sistema mode, ngunit PID
hindi 1. Sa pagsasanay, pagpasa --sistema tahasang ay kapaki-pakinabang lamang kasabay ng
--pagsusulit.

--dump-core
Paganahin ang core dumping sa pag-crash. Walang epekto ang switch na ito kapag tumatakbo bilang user instance.
Ang setting na ito ay maaari ding paganahin sa panahon ng boot sa kernel command line sa pamamagitan ng
systemd.dump_core= opsyon, tingnan sa ibaba.

--crash-vt=VT
Lumipat sa isang partikular na virtual console (VT) sa pag-crash. Kumukuha ng positive integer sa
range 1–63, o isang boolean argument. Kung naipasa ang isang integer, pipiliin kung aling VT ang lilipat
sa. Kung oo, napili ang mga mensahe ng kernel ng VT kung saan isinulat. Kung hindi, walang switch ng VT
sinubukan. Walang epekto ang switch na ito kapag tumatakbo bilang user instance. Ang setting na ito ay maaaring
paganahin din sa panahon ng boot, sa kernel command line sa pamamagitan ng systemd.crash_vt=
opsyon, tingnan sa ibaba.

--crash-shell
Magpatakbo ng shell sa pag-crash. Walang epekto ang switch na ito kapag tumatakbo bilang user instance. Ito
ang setting ay maaari ding paganahin sa panahon ng boot, sa kernel command line sa pamamagitan ng
systemd.crash_shell= opsyon, tingnan sa ibaba.

--crash-reboot
Awtomatikong i-reboot ang system kapag nag-crash. Ang switch na ito ay walang epekto kapag tumatakbo bilang
halimbawa ng gumagamit. Ang setting na ito ay maaari ding paganahin sa panahon ng boot, sa kernel command
linya sa pamamagitan ng systemd.crash_reboot= opsyon, tingnan sa ibaba.

--kumpirmahin-spawn
Humingi ng kumpirmasyon kapag nagproseso ng pangingitlog. Ang switch na ito ay walang epekto kapag tumakbo bilang
halimbawa ng gumagamit.

--show-status=
Ipakita ang maikling impormasyon ng katayuan ng serbisyo habang nagbo-boot. Ang switch na ito ay walang epekto kapag
tumakbo bilang halimbawa ng user. Kumuha ng boolean argument na maaaring tanggalin which is
binibigyang kahulugan bilang totoo.

--log-target=
Itakda ang target ng log. Ang argumento ay dapat isa sa mag-aliw, talaarawan, kmsg, journal-o-kmsg, walang halaga.

--log-level=
Itakda ang antas ng log. Bilang argumento ito ay tumatanggap ng isang numerical log level o ang kilala
syslog(3) mga simbolikong pangalan (maliit na titik): lumilitaw, alerto, si crit, maligaw, babala, abiso, info,
mag-alis ng mga insekto.

--log-color=
I-highlight ang mahahalagang mensahe ng log. Ang argumento ay isang boolean na halaga. Kung ang argumento ay
tinanggal, ito ay default sa totoo.

--log-lokasyon=
Isama ang lokasyon ng code sa mga mensahe ng log. Ito ay kadalasang nauugnay para sa mga layunin ng pag-debug.
Ang argumento ay isang boolean na halaga. Kung ang argumento ay tinanggal ito ay magiging default sa totoo.

--default-standard-output=, --default-standard-error=
Itinatakda ang default na output o error na output para sa lahat ng mga serbisyo at socket, ayon sa pagkakabanggit.
Ibig sabihin, kinokontrol ang default para sa StandardOutput= at StandardError= (Tingnan ang
systemd.exec(5) para sa mga detalye). Kumuha ng isa sa magmana, walang halaga, tty, talaarawan,
journal+console, syslog, syslog+console, kmsg, kmsg+console. Kung ang argumento ay
tinanggal --default-standard-output= default sa talaarawan at --default-standard-error=
sa magmana.

--machine-id=
I-override ang machine-id set sa hard drive, kapaki-pakinabang para sa network booting o para sa
mga lalagyan. Maaaring hindi itakda sa lahat ng mga zero.

-h, - Tumulong
Mag-print ng isang maikling teksto ng tulong at exit.

--bersyon
Mag-print ng maikling bersyon na string at exit.

KONSEPTO

Ang systemd ay nagbibigay ng isang dependency system sa pagitan ng iba't ibang entity na tinatawag na "mga yunit" ng 12
iba't ibang uri. Ang mga unit ay nagsa-encapsulate ng iba't ibang bagay na may kaugnayan para sa system boot-up
at pagpapanatili. Ang karamihan ng mga unit ay naka-configure sa mga file ng configuration ng unit, na kung saan
syntax at pangunahing hanay ng mga opsyon ay inilarawan sa systemd.unit(5), gayunpaman ang ilan ay nilikha
awtomatikong mula sa iba pang configuration, dynamic na mula sa system state o programmatically
sa runtime. Ang mga unit ay maaaring "aktibo" (ibig sabihin ay nagsimula, nakatali, nakasaksak, ..., depende sa
ang uri ng unit, tingnan sa ibaba), o "hindi aktibo" (ibig sabihin ay huminto, hindi nakatali, na-unplug, ...), bilang
pati na rin sa proseso ng pagiging aktibo o hindi aktibo, ibig sabihin, sa pagitan ng dalawang estado
(ang mga estadong ito ay tinatawag na "pag-activate", "pag-deactivate"). Ang isang espesyal na "nabigo" na estado ay
magagamit din, na halos kapareho sa "hindi aktibo" at ipinasok kapag ang serbisyo
nabigo sa ilang paraan (nagbalik ang proseso ng error code sa paglabas, o nag-crash, o isang operasyon na nag-time
palabas). Kung ang estado na ito ay ipinasok, ang dahilan ay mai-log, para sa sanggunian sa ibang pagkakataon. Tandaan na
ang iba't ibang uri ng unit ay maaaring may ilang karagdagang mga substate, na nakamapa sa
limang pangkalahatang estado ng yunit na inilarawan dito.

Available ang mga sumusunod na uri ng unit:

1. Mga unit ng serbisyo, na nagsisimula at kumokontrol sa mga daemon at sa mga prosesong binubuo ng mga ito. Para sa
mga detalye, tingnan systemd.serviceNa (5).

2. Ang mga socket unit, na nagpapaloob sa lokal na IPC o mga network socket sa system, ay kapaki-pakinabang para sa
activation na nakabatay sa socket. Para sa mga detalye tungkol sa mga socket unit, tingnan systemd.socket(5), para sa
mga detalye sa pag-activate na nakabatay sa socket at iba pang paraan ng pag-activate, tingnan demonyoNa (7).

3. Ang mga target na unit ay kapaki-pakinabang sa mga unit ng pangkat, o nagbibigay ng mga kilalang punto ng pag-synchronize
sa panahon ng boot-up, tingnan systemd.targetNa (5).

4. Inilalantad ng mga unit ng device ang mga kernel device sa systemd at maaaring gamitin para ipatupad
activation na nakabatay sa device. Para sa mga detalye, tingnan systemd.deviceNa (5).

5. Kinokontrol ng mga unit ng Mount ang mga mount point sa file system, para sa mga detalye tingnan systemd.mountNa (5).

6. Ang mga automount unit ay nagbibigay ng mga kakayahan sa automount, para sa on-demand na pag-mount ng mga file system
pati na rin ang parallelized boot-up. Tingnan mo systemd.automountNa (5).

7. Ang mga yunit ng timer ay kapaki-pakinabang para sa pag-trigger ng pag-activate ng iba pang mga yunit batay sa mga timer. Ikaw
maaaring mahanap ang mga detalye sa systemd.timerNa (5).

8. Ang mga swap unit ay halos kapareho sa mount units at nag-encapsulate ng memory swap partition o
mga file ng operating system. Ang mga ito ay inilarawan sa systemd.swapNa (5).

9. Maaaring gamitin ang mga unit ng landas upang i-activate ang iba pang mga serbisyo kapag nagbago ang mga object ng file system o
ay binago. Tingnan mo systemd.pathNa (5).

10. Maaaring gamitin ang mga slice unit upang pangkatin ang mga unit na namamahala sa mga proseso ng system (tulad ng serbisyo
at mga yunit ng saklaw) sa isang hierarchical tree para sa mga layunin ng pamamahala ng mapagkukunan. Tingnan mo
systemd.sliceNa (5).

11. Ang mga yunit ng saklaw ay katulad ng mga yunit ng serbisyo, ngunit pinamamahalaan ang mga dayuhang proseso sa halip na
simulan na rin sila. Tingnan mo systemd.scopeNa (5).

Ang mga unit ay pinangalanan bilang kanilang mga configuration file. Ang ilang mga yunit ay may mga espesyal na semantika. A
ang detalyadong listahan ay magagamit sa systemd.espesyalNa (7).

Alam ng systemd ang iba't ibang uri ng dependencies, kabilang ang positibo at negatibong kinakailangan
dependencies (hal Nangangailangan= at Mga salungatan=) pati na rin ang pag-order ng mga dependencies (Pagkatapos = at
Bago =). NB: orthogonal ang pag-order at mga dependency sa kinakailangan. Kung requirement lang
Ang dependency ay umiiral sa pagitan ng dalawang unit (hal. foo.service ay nangangailangan ng bar.service), ngunit hindi
pag-order ng dependency (hal. foo.service pagkatapos ng bar.service) at pareho silang hiniling na magsimula,
sila ay magsisimula sa parallel. Ito ay isang karaniwang pattern na parehong kinakailangan at
ang mga dependency sa pag-order ay inilalagay sa pagitan ng dalawang unit. Tandaan din na ang karamihan ng
Ang mga dependency ay tahasang nilikha at pinapanatili ng systemd. Sa karamihan ng mga kaso, ito ay dapat na
hindi kinakailangang magdeklara ng mga karagdagang dependency nang manu-mano, gayunpaman posible itong gawin
na ito.

Ang mga application program at unit (sa pamamagitan ng mga dependency) ay maaaring humiling ng mga pagbabago sa estado ng mga unit. Sa
systemd, ang mga kahilingang ito ay naka-encapsulated bilang 'mga trabaho' at pinananatili sa isang pila ng trabaho. Maaaring ang mga trabaho
magtagumpay o maaaring mabigo, ang kanilang pagpapatupad ay iniutos batay sa pag-order ng mga dependencies ng
mga yunit na kanilang naka-iskedyul.

Sa boot systemd ina-activate ang target na unit default.target na ang trabaho ay i-activate ang on-boot
mga serbisyo at iba pang on-boot unit sa pamamagitan ng paghila sa kanila sa pamamagitan ng mga dependency. Kadalasan, ang unit
pangalan ay isa lamang alyas (symlink) para sa alinman sa graphical.target (para sa ganap na tampok na mga bota sa
ang UI) o multi-user.target (para sa limitadong console-only na bota para gamitin sa naka-embed o server
kapaligiran, o katulad; isang subset ng graphical.target). Gayunpaman, ito ay nasa pagpapasya
ng administrator upang i-configure ito bilang isang alias sa anumang iba pang target na unit. Tingnan mo
systemd.espesyal(7) para sa mga detalye tungkol sa mga target na unit na ito.

Ang mga proseso ng systemd spawns ay inilalagay sa mga indibidwal na grupo ng kontrol ng Linux na pinangalanan pagkatapos ng
yunit kung saan sila nabibilang sa pribadong systemd hierarchy. (tingnan cgroups.txt[1] para sa higit pa
impormasyon tungkol sa mga control group, o maikling "cgroups"). ginagamit ito ng systemd upang mabisa
subaybayan ang mga proseso. Ang impormasyon ng control group ay pinananatili sa kernel, at ito ay
maa-access sa pamamagitan ng hierarchy ng file system (sa ilalim /sys/fs/cgroup/systemd/), o sa mga kasangkapan
tulad ng systemd-cgls(1) o ps(1) (ps xawf -eo pid, user, cgroup, args ay partikular na kapaki-pakinabang
upang ilista ang lahat ng mga proseso at ang mga systemd unit na kinabibilangan nila.).

systemd ay katugma sa SysV init system sa isang malaking antas: SysV init script ay
suportado at simpleng basahin bilang isang alternatibo (bagaman limitado) na format ng configuration file.
Ang SysV /dev/initctl interface ay ibinigay, at compatibility pagpapatupad ng
iba't ibang mga tool ng kliyente ng SysV ay magagamit. Bilang karagdagan, ang iba't ibang itinatag na Unix
functionality tulad ng / etc / fstab o ang utmp database ay suportado.

systemd ay may kaunting sistema ng transaksyon: kung ang isang yunit ay hiniling na magsimula o magsara
idaragdag nito ito at lahat ng mga dependency nito sa isang pansamantalang transaksyon. Pagkatapos, ito ay magbe-verify
kung pare-pareho ang transaksyon (ibig sabihin, kung ang pag-order ng lahat ng unit ay cycle-free).
Kung hindi, susubukan ng systemd na ayusin ito, at aalisin ang mga hindi mahahalagang trabaho mula sa
transaksyon na maaaring mag-alis ng loop. Gayundin, sinusubukan ng systemd na sugpuin ang mga hindi mahahalagang trabaho
sa transaksyon na magpapahinto sa tumatakbong serbisyo. Sa wakas ay nasusuri kung ang
ang mga trabaho ng transaksyon ay sumasalungat sa mga trabahong nakapila na, at opsyonal ang
naabort ang transaksyon pagkatapos. Kung ang lahat ay nagtrabaho out at ang transaksyon ay pare-pareho at
pinaliit sa epekto nito ito ay pinagsama sa lahat ng mga natitirang trabaho at idinagdag sa
tumakbo ng pila. Epektibong nangangahulugan ito na bago magsagawa ng hiniling na operasyon, systemd
ay magpapatunay na ito ay makatuwiran, ayusin ito kung maaari, at mabibigo lamang kung ito talaga
hindi maaaring gumana.

Ang Systemd ay naglalaman ng mga katutubong pagpapatupad ng iba't ibang mga gawain na kailangang isagawa bilang bahagi
ng proseso ng boot. Halimbawa, itinatakda nito ang hostname o kino-configure ang loopback network
aparato. Nagse-set up at nag-mount din ito ng iba't ibang mga API file system, gaya ng / sys o /proc.

Para sa karagdagang impormasyon tungkol sa mga konsepto at ideya sa likod ng systemd, mangyaring sumangguni sa
Orihinal Disenyo Dokumento[2].

Tandaan na ang ilan ngunit hindi lahat ng mga interface na ibinigay ng systemd ay sakop ng interface
Katatagan Pangako[3].

Maaaring dynamic na mabuo ang mga unit sa oras ng pag-reload ng boot at system manager, halimbawa
batay sa iba pang configuration file o mga parameter na ipinasa sa kernel command line. Para sa
mga detalye, tingnan systemd.generatorNa (7).

Ang mga system na humihiling ng systemd sa isang lalagyan o initrd na kapaligiran ay dapat ipatupad ang
Lalagyan interface[4] o initrd interface[5] mga detalye, ayon sa pagkakabanggit.

MGA DIREKTORY

Mga direktoryo ng unit ng system
Binabasa ng systemd system manager ang configuration ng unit mula sa iba't ibang direktoryo. Mga package
na gustong mag-install ng mga file ng unit ay dapat ilagay ang mga ito sa direktoryo na ibinalik ni
pkg-config systemd --variable=systemdsystemunitdir. Ang iba pang mga direktoryo na sinuri ay
/usr/local/lib/systemd/system at /lib/systemd/system. Palaging tumatagal ang configuration ng user
karapatan sa pangunguna. pkg-config systemd --variable=systemdsystemconfdir ibinabalik ang landas ng
ang direktoryo ng pagsasaayos ng system. Dapat baguhin ng mga package ang nilalaman ng mga ito
mga direktoryo lamang na may paganahin at huwag paganahin mga utos ng systemctl(1) kasangkapan. Puno
listahan ng mga direktoryo ay ibinigay sa systemd.unitNa (5).

Mga direktoryo ng unit ng gumagamit
Nalalapat ang mga katulad na panuntunan para sa mga direktoryo ng unit ng user. Gayunpaman, dito ang XDG Base
Directory detalye[6] ay sinusundan upang mahanap ang mga yunit. Dapat ilagay ng mga aplikasyon ang kanilang
unit file sa direktoryo na ibinalik ni pkg-config systemd
--variable=systemduserunitdir. Ginagawa ang pandaigdigang pagsasaayos sa iniulat na direktoryo
by pkg-config systemd --variable=systemduserconfdir. ang paganahin at huwag paganahin utos
ng systemctl(1) Kakayanin ng tool ang parehong global (ibig sabihin, para sa lahat ng mga gumagamit) at pribado (para sa
isang user) pagpapagana/hindi pagpapagana ng mga unit. Ang buong listahan ng mga direktoryo ay ibinigay sa
systemd.unitNa (5).

Direktoryo ng mga script ng SysV init
Ang lokasyon ng SysV init script na direktoryo ay nag-iiba sa pagitan ng mga distribusyon. Kung
hindi mahanap ng systemd ang isang native unit file para sa isang hiniling na serbisyo, maghahanap ito ng a
SysV init script na may kaparehong pangalan (na inalis ang .service suffix).

SysV runlevel link farm directory
Ang lokasyon ng SysV runlevel link farm directory ay nag-iiba-iba sa pagitan ng mga distribusyon.
Isasaalang-alang ng systemd ang link farm kapag inaalam kung dapat ang isang serbisyo
paganahin. Tandaan na hindi maaaring ang isang service unit na may native unit configuration file
nagsimula sa pamamagitan ng pag-activate nito sa SysV runlevel link farm.

Mga TANDA

TARGET TERM
Sa pagtanggap ng signal na ito, ang systemd system manager ay nagse-serialize ng estado nito, muling ipapatupad
ang sarili nito at muling sinisira ang naligtas na estado. Ito ay halos katumbas ng systemctl
daemon-reexec.

Sisimulan ng mga systemd user manager ang exit.target unit kapag natanggap ang signal na ito.
Ito ay halos katumbas ng systemctl --gumagamit simula labasan.target.

TANDAAN
Sa pagtanggap ng signal na ito, sisimulan ng systemd system manager ang
ctrl-alt-del.target unit. Ito ay halos katumbas ng systemctl simula
ctl-alt-del.target. Kung ang signal na ito ay natanggap nang higit sa 7 beses bawat 2s, isang agarang
na-trigger ang pag-reboot. Tandaan na ang pagpindot sa Ctrl-Alt-Del sa console ay magti-trigger nito
hudyat. Kaya, kung ang isang reboot ay nakabitin, pindutin ang Ctrl-Alt-Del nang higit sa 7 beses sa loob ng 2s
ay isang medyo ligtas na paraan upang ma-trigger ang isang agarang pag-reboot.

tinatrato ng mga systemd user manager ang signal na ito sa parehong paraan tulad ng TARGET TERM.

SIGWINCH
Kapag natanggap ang signal na ito, sisimulan ng systemd system manager ang
kbrequest.target na yunit. Ito ay halos katumbas ng systemctl simula kbrequest.target.

Ang signal na ito ay hindi pinapansin ng mga systemd user manager.

SIGPWR
Kapag natanggap ang signal na ito, sisimulan ng systemd manager ang sigpwr.target unit.
Ito ay halos katumbas ng systemctl simula sigpwr.target.

SIGUSR1
Kapag natanggap ang signal na ito, susubukan ng systemd manager na muling kumonekta sa D-Bus
bus

SIGUSR2
Kapag natanggap ang signal na ito, itatala ng systemd manager ang kumpletong estado nito
anyo na nababasa ng tao. Ang data na naka-log ay kapareho ng na-print ni systemd-analisa tambakan ng basura.

FOLLOW UP
Nire-reload ang kumpletong configuration ng daemon. Ito ay halos katumbas ng systemctl
daemon-reload.

SIGRTMIN+0
Pumapasok sa default mode, magsisimula sa default.target na unit. Ito ay halos katumbas ng
systemctl simula default.target.

SIGRTMIN+1
Papasok sa rescue mode, sisimulan ang rescue.target unit. Ito ay halos katumbas ng
systemctl ihiwalay iligtas.target.

SIGRTMIN+2
Papasok sa emergency mode, sisimulan ang emergency.service unit. Ito ay halos katumbas ng
systemctl ihiwalay emergency.serbisyo.

SIGRTMIN+3
Pinahinto ang makina, sinisimulan ang halt.target unit. Ito ay halos katumbas ng systemctl
simula huminto.target.

SIGRTMIN+4
Pinapatay ang makina, sisimulan ang poweroff.target unit. Ito ay halos katumbas ng
systemctl simula poweroff.target.

SIGRTMIN+5
Nire-reboot ang makina, sisimulan ang reboot.target unit. Ito ay halos katumbas ng
systemctl simula reboot.target.

SIGRTMIN+6
Nire-reboot ang makina sa pamamagitan ng kexec, sisimulan ang kexec.target unit. Ito ay halos katumbas
sa systemctl simula kexec.target.

SIGRTMIN+13
Agad na pinahinto ang makina.

SIGRTMIN+14
Agad na pinatay ang makina.

SIGRTMIN+15
Agad na i-reboot ang makina.

SIGRTMIN+16
Kaagad na i-reboot ang makina gamit ang kexec.

SIGRTMIN+20
Pinapagana ang pagpapakita ng mga status message sa console, gaya ng kinokontrol sa pamamagitan ng
systemd.show_status=1 sa kernel command line.

SIGRTMIN+21
Hindi pinapagana ang pagpapakita ng mga status message sa console, gaya ng kinokontrol sa pamamagitan ng
systemd.show_status=0 sa kernel command line.

SIGRTMIN+22, SIGRTMIN+23
Itinatakda ang antas ng log sa "debug" (o "impormasyon" sa SIGRTMIN+23), bilang kinokontrol sa pamamagitan ng
systemd.log_level=debug (O systemd.log_level=info on SIGRTMIN+23) sa kernel
command line.

SIGRTMIN+24
Kaagad na lumabas sa manager (available lang para sa --user instance).

SIGRTMIN+26, SIGRTMIN+27, SIGRTMIN+28
Itinatakda ang antas ng log sa "journal-or-kmsg" (o "console" sa SIGRTMIN+27, "kmsg" sa
SIGRTMIN+28), bilang kinokontrol sa pamamagitan ng systemd.log_target=journal-or-kmsg (O
systemd.log_target=console on SIGRTMIN+27 or systemd.log_target=kmsg on SIGRTMIN+28)
sa kernel command line.

Kapaligiran

$SYSTEMD_LOG_LEVEL
Binabasa ng systemd ang antas ng log mula sa variable na kapaligiran na ito. Maaari itong ma-override
sa --log-level=.

$SYSTEMD_LOG_TARGET
Binabasa ng systemd ang log target mula sa environment variable na ito. Maaari itong ma-override
sa --log-target=.

$SYSTEMD_LOG_COLOR
Kinokontrol kung ang systemd ay nagha-highlight ng mahahalagang mensahe ng log. Maaari itong ma-override
sa --log-color=.

$SYSTEMD_LOG_LOCATION
Kinokontrol kung ipi-print ng systemd ang lokasyon ng code kasama ng mga mensahe ng log. Ito ay maaaring
na-override ng --log-lokasyon=.

$XDG_CONFIG_HOME, $XDG_CONFIG_DIRS, $XDG_DATA_HOME, $XDG_DATA_DIRS
Ginagamit ng systemd user manager ang mga variable na ito alinsunod sa XDG Base Directory
detalye[6] upang mahanap ang pagsasaayos nito.

$SYSTEMD_UNIT_PATH
Kinokontrol kung saan hinahanap ng systemd ang mga file ng unit.

$SYSTEMD_SYSVINIT_PATH
Mga kontrol kung saan hinahanap ng systemd ang mga script ng SysV init.

$SYSTEMD_SYSVRCND_PATH
Mga kontrol kung saan hinahanap ng systemd ang SysV init script runlevel link farm.

$SYSTEMD_COLORS
Kinokontrol kung dapat mabuo ang may kulay na output.

$LISTEN_PID, $LISTEN_FDS, $LISTEN_FDNAMES
Itinakda ng systemd para sa mga pinangangasiwaang proseso sa panahon ng pag-activate na nakabatay sa socket. Tingnan mo
sd_listen_fds(3) para sa karagdagang impormasyon.

$NOTIFY_SOCKET
Itinakda ng systemd para sa mga pinangangasiwaang proseso para sa katayuan at pagkumpleto ng pagsisimula
abiso. Tingnan mo sd_notify(3) para sa karagdagang impormasyon.

KERNEL COMMAND LINE

Kapag tumakbo bilang system instance systemd ay nag-parse ng isang bilang ng kernel command line arguments[7]:

systemd.unit=, rd.systemd.unit=
Ino-override ang unit para i-activate sa boot. Default sa default.target. Ito ay maaaring gamitin
para pansamantalang mag-boot sa ibang boot unit, halimbawa rescue.target o
emergency.serbisyo. Tingnan mo systemd.espesyal(7) para sa mga detalye tungkol sa mga yunit na ito. Ang pagpipilian
nilagyan ng prefix na "rd." ay pinarangalan lamang sa paunang RAM disk (initrd), habang ang isa
na hindi prefixed lamang sa pangunahing sistema.

systemd.dump_core=
Kumuha ng boolean argument. Kung oo, ang systemd manager (PID 1) ay nagtatapon ng core kapag ito
nag-crash. Kung hindi, walang gagawing core dump. Default sa oo.

systemd.crash_chvt=
Kumukuha ng positive integer, o boolean argument. Kung ang isang positibong integer (sa hanay
1–63) ay tinukoy, ang system manager (PID 1) ay isaaktibo ang tinukoy na virtual
terminal (VT) kapag nag-crash ito. Default sa hindi, ibig sabihin ay walang ganoong switch
sinubukan. Kung nakatakda sa oo, ang VT kung saan nakasulat ang mga mensahe ng kernel ay napili.

systemd.crash_shell=
Kumuha ng boolean argument. Kung oo, ang system manager (PID 1) ay naglalabas ng shell kapag ito
nag-crash, pagkatapos ng 10s na pagkaantala. Kung hindi, walang shell na na-spawned. Default sa hindi, Para sa
dahil sa seguridad, dahil ang shell ay hindi protektado ng pagpapatunay ng password.

systemd.crash_reboot=
Kumuha ng boolean argument. Kung oo, ire-reboot ng system manager (PID 1) ang makina
awtomatikong kapag nag-crash ito, pagkatapos ng 10s pagkaantala. Kung hindi, ang sistema ay mag-hang
walang katiyakan. Default sa hindi, para maiwasan ang reboot loop. Kung isasama sa
systemd.crash_shell=, nire-reboot ang system pagkatapos lumabas ang shell.

systemd.confirm_spawn=
Kumuha ng boolean argument. Kung oo, humihingi ng kumpirmasyon ang system manager (PID 1).
kapag mga proseso ng pangingitlog. Default sa hindi.

systemd.show_status=
Kumuha ng boolean argument o pare-pareho kotse. Kung oo, ang systemd manager (PID 1)
nagpapakita ng mga maikling update sa katayuan ng serbisyo sa console sa panahon ng bootup. kotse kumikilos tulad ng
hindi totoo hanggang sa mabigo ang isang serbisyo o may malaking pagkaantala sa boot. Default sa oo,
maliban na lamang kung tahimik ay ipinasa bilang kernel command line na opsyon, kung saan ito ay magiging default sa
kotse.

systemd.log_target=, systemd.log_level=, systemd.log_color=, systemd.log_location=
Kinokontrol ang output ng log, na may parehong epekto gaya ng $SYSTEMD_LOG_TARGET,
$SYSTEMD_LOG_LEVEL, $SYSTEMD_LOG_COLOR, $SYSTEMD_LOG_LOCATION mga variable ng kapaligiran
inilarawan sa itaas.

systemd.default_standard_output=, systemd.default_standard_error=
Kinokontrol ang default na karaniwang output at error na output para sa mga serbisyo, na may parehong epekto
bilang --default-standard-output= at --default-standard-error= mga argumento ng linya ng utos
inilarawan sa itaas, ayon sa pagkakabanggit.

systemd.setenv=
Kumuha ng string argument sa form na VARIABLE=VALUE. Maaaring gamitin upang itakda ang default
mga variable ng kapaligiran upang idagdag sa mga proseso ng forked na bata. Maaaring gamitin nang higit sa isang beses upang
magtakda ng maramihang mga variable.

systemd.machine_id=
Kumukuha ng 32 character na hex value na gagamitin para sa pagtatakda ng machine-id. Inilaan karamihan
para sa network booting kung saan ang parehong machine-id ay nais para sa bawat boot.

tahimik
I-off ang status output sa boot, katulad ng systemd.show_status=false ay. Tandaan na
ang pagpipiliang ito ay binabasa din ng kernel mismo at hindi pinapagana ang output ng kernel log. pagpasa
ang pagpipiliang ito samakatuwid ay pinapatay ang karaniwang output mula sa system manager at sa
kernel

mag-alis ng mga insekto
I-on ang output ng pag-debug. Ito ay katumbas ng systemd.log_level=debug. Tandaan na
ang pagpipiliang ito ay binabasa din ng kernel mismo at nagbibigay-daan sa output ng kernel debug. pagpasa
ang pagpipiliang ito samakatuwid ay i-on ang debug na output mula sa system manager at sa
kernel

kagipitan, -b
Mag-boot sa emergency mode. Ito ay katumbas ng systemd.unit=emergency.target at
ibinigay para sa mga dahilan ng pagiging tugma at para mas madaling mag-type.

iligtas, solong, s, S, 1
Mag-boot sa rescue mode. Ito ay katumbas ng systemd.unit=rescue.target at ibinigay
para sa mga dahilan ng compatibility at para mas madaling mag-type.

2, 3, 4, 5
Mag-boot sa tinukoy na legacy na SysV runlevel. Ang mga ito ay katumbas ng
systemd.unit=runlevel2.target, systemd.unit=runlevel3.target,
systemd.unit=runlevel4.target, at systemd.unit=runlevel5.target, ayon sa pagkakabanggit, at
ibinigay para sa mga dahilan ng pagiging tugma at para mas madaling mag-type.

locale.LANG=, locale.LANGUAGE=, locale.LC_CTYPE=, locale.LC_NUMERIC=, locale.LC_TIME=,
locale.LC_COLLATE=, locale.LC_MONETARY=, locale.LC_MESSAGES=, locale.LC_PAPER=,
locale.LC_NAME=, locale.LC_ADDRESS=, locale.LC_TELEPHONE=, locale.LC_MEASUREMENT=,
locale.LC_IDENTIFICATION=
Itakda ang locale ng system na gagamitin. Ino-override nito ang mga setting sa /etc/locale.conf. Para sa
higit pang impormasyon, tingnan locale.conf(5) at lokalNa (7).

Para sa iba pang mga parameter ng command line ng kernel na nauunawaan ng mga bahagi ng core OS, mangyaring
sumangguni sa kernel-command-lineNa (7).

MGA SOCKET AT FIFOS

/run/systemd/notify
Socket ng notification ng status ng Daemon. Ito ay isang AF_UNIX datagram socket at ginagamit sa
ipatupad ang logic ng notification ng daemon gaya ng ipinatupad ni sd_notifyNa (3).

/run/systemd/private
Ginagamit sa loob bilang channel ng komunikasyon sa pagitan systemctl(1) at ang systemd na proseso.
Ito ay isang AF_UNIX stream socket. Ang interface na ito ay pribado sa systemd at hindi dapat
gamitin sa mga panlabas na proyekto.

/dev/initctl
Limitadong suporta sa compatibility para sa SysV client interface, gaya ng ipinatupad ng
systemd-initctl.service unit. Ito ay pinangalanang pipe sa file system. Ang interface na ito
ay lipas na at hindi dapat gamitin sa mga bagong application.

Gumamit ng systemd online gamit ang mga serbisyo ng onworks.net