PricingLoginStart free
Linux-komentorivin ja Bash-komentosarjojen hallinta · Oppitunti

systemd-palveluiden hallinta ja unit-tiedostojen kirjoittaminen

Ohjaa palveluita systemctlillä ja kirjoita mukautettuja unit- ja ajastintiedostoja skriptattaville daemon-palveluille.

Oppitunti 2/413 vaihetta

systemd-palveluiden hallinta ja unit-tiedostojen kirjoittaminen on ilmainen Linux-komentorivin ja Bash-komentosarjojen hallinta-oppitunti CoddyKitissä. Tämä on oppitunti 2/4. Voit lukea koko oppitunnin alta ilmaiseksi ja harjoitella sen jälkeen käytännössä selaimessa sisäänrakennetulla koodieditorilla ja ympäri vuorokauden käytettävissä olevan tekoälytuutorin avulla. Oppitunti kuuluu Linux-komentorivin ja Bash-komentosarjojen hallinta-oppimispolkuun, ja edistymisesi synkronoituu verkon ja CoddyKit-sovelluksen välillä. Linux-komentorivin ja Bash-komentosarjojen hallinta-kurssilla on yhteensä 4 oppituntia.

systemd:n ja systemctl:n esittely

systemd on useimpien nykyaikaisten Linux-jakeluiden init-järjestelmä ja palveluiden hallintaohjelmisto. Se vastaa järjestelmäpalveluiden käynnistämisestä, pysäyttämisestä ja hallinnasta sekä käynnistysprosessien ja järjestelmän tilan käsittelystä.

Ensisijainen työkalu systemd:n kanssa toimimiseen on systemctl. Sen avulla voitte:

  • käynnistää ja pysäyttää palveluita
  • ottaa palveluita käyttöön tai poistaa niitä käytöstä käynnistyksen yhteydessä
  • tarkastella palveluiden tilaa ja lokeja
  • ladata asetukset uudelleen ilman uudelleenkäynnistystä

Kaikki systemd:n hallitsemat palvelut määritellään unit-tiedostoissa, jotka ovat deklaratiivisia asetustiedostoja. Ne sijaitsevat hakemistossa /etc/systemd/system/ (koko järjestelmän laajuiset asetukset) tai hakemistossa ~/.config/systemd/user/ (käyttäjäkohtaiset asetukset).

Keskeiset systemctl-komennot

Nämä ovat yleisimmin käytetyt systemctl-komennot palveluiden päivittäiseen hallintaan. Jokainen komento käsittelee yksikön nimeä, kuten nginx.service tai yksinkertaisesti nginx.

  • systemctl start <unit> — käynnistää palvelun välittömästi
  • systemctl stop <unit> — pysäyttää käynnissä olevan palvelun
  • systemctl restart <unit> — pysäyttää palvelun ja käynnistää sen sitten uudelleen (täydellinen uudelleenkäynnistys)
  • systemctl reload <unit> — lähettää SIGHUP-signaalin asetusten lataamiseksi uudelleen ilman pysäytystä
  • systemctl enable <unit> — luo symboliset linkit, jotta yksikkö käynnistyy järjestelmän käynnistyessä
  • systemctl disable <unit> — poistaa kyseiset symboliset linkit
  • systemctl status <unit> — näyttää tilan, PID-tunnisteen ja viimeisimmät lokirivit
#!/usr/bin/env bash
# Quick reference: inspect and control an nginx service
# (Requires nginx to be installed; run as root or with sudo)

systemctl status nginx
systemctl start nginx
systemctl enable nginx
systemctl reload nginx
systemctl restart nginx
systemctl stop nginx
systemctl disable nginx

Palvelun tilan tarkistaminen yksityiskohtaisesti

systemctl status näyttää yksiköstä kattavan tilannekuvan. Tulosteen ymmärtäminen on olennaista ongelmien nopeassa diagnosoinnissa.

  • Loaded: yksikkötiedoston polku ja tieto siitä, onko yksikkö käytössä järjestelmän käynnistyessä
  • Active: nykyinen tila — active (running), inactive (dead), failed
  • Main PID: palvelun pääprosessin prosessitunniste
  • CGroup: kaikki palveluun kuuluvat aliprosessit
  • Log lines: tämän yksikön viimeisimmät journal-merkinnät

Voitte myös kysellä pelkän aktiivisen tilan komennolla systemctl is-active ja käyttöönottotilan komennolla systemctl is-enabled. Ne sopivat erityisen hyvin skripteissä käytettäviksi.

#!/usr/bin/env bash
# Script-friendly service health check
SERVICE="sshd"

if systemctl is-active --quiet "$SERVICE"; then
    echo "$SERVICE is running."
else
    echo "$SERVICE is NOT running. Attempting restart..."
    systemctl restart "$SERVICE"
fi

if systemctl is-enabled --quiet "$SERVICE"; then
    echo "$SERVICE is enabled at boot."
else
    echo "WARNING: $SERVICE is not enabled at boot."
fi

Yksiköiden luetteloiminen ja suodattaminen

Kun hallittavana on useita palveluita, tarvitsette tehokkaita tapoja yksiköiden luetteloimiseen ja suodattamiseen. systemctl list-units näyttää kaikki tällä hetkellä ladatut yksiköt, kun taas list-unit-files näyttää kaikki asennetut yksikkötiedostot ja niiden käyttöönottotilan.

Hyödyllisiä suodatusasetuksia:

  • --type=service — näyttää vain palveluyksiköt
  • --state=failed — näyttää vain epäonnistuneet yksiköt
  • --state=active — näyttää vain aktiiviset yksiköt
  • --all — sisällyttää passiiviset yksiköt luetteloon

Kun yhdistätte nämä suodattimet komentoon grep, voitte rakentaa tehokkaita tarkistusputkia ylläpitoskripteihin.

#!/usr/bin/env bash
# List all failed services and report them
echo "=== Failed Services ==="
systemctl list-units --type=service --state=failed --no-legend

echo ""
echo "=== Services Enabled at Boot ==="
systemctl list-unit-files --type=service --state=enabled --no-legend | awk '{print $1}'

systemd-palveluyksikkötiedoston rakenne

Palveluyksikkötiedosto on osioista koostuva pelkkä tekstitiedosto INI-tyyliin. Kukin osio hallitsee yksikön elinkaaren eri osa-aluetta.

  • [Unit] — metatiedot: kuvaus ja suoritusjärjestyksen riippuvuudet (After=, Requires=, Wants=)
  • [Service] — miten prosessi käynnistetään ja pysäytetään: ExecStart, ExecStop, Restart, User, WorkingDirectory
  • [Install] — milloin tämä yksikkö otetaan käyttöön: WantedBy=multi-user.target tarkoittaa, että se aktivoidaan normaalin monen käyttäjän käynnistyksen aikana

Kun olette sijoittaneet yksikkötiedoston hakemistoon /etc/systemd/system/ tai muokanneet sitä siellä, suorittakaa systemctl daemon-reload, jotta systemd ottaa muutokset käyttöön.

Ensimmäisen palveluyksikkötiedoston kirjoittaminen

Luodaan yksinkertainen palveluyksikkötiedosto mukautetulle Python-HTTP-palvelinskriptille. Yksikkötiedosto kertoo systemd:lle täsmällisesti, miten tätä prosessia hallitaan aivan kuten mitä tahansa muuta järjestelmäpalvelua.

Tässä käytetyt tärkeät [Service]-direktiivit:

  • Type=simple — systemd käsittelee ExecStart-prosessia pääprosessina
  • User=www-data — suoritetaan ei-root-käyttäjätilillä turvallisuuden parantamiseksi
  • WorkingDirectory — määrittää prosessin työskentelyhakemiston
  • Restart=on-failure — käynnistää prosessin automaattisesti uudelleen, jos se päättyy nollasta poikkeavaan paluuarvoon
  • RestartSec=5 — odottaa uudelleenkäynnistysyritysten välillä 5 sekuntia
#!/usr/bin/env bash
# Create a custom service unit file for a simple HTTP server
# Run as root

cat > /etc/systemd/system/mywebserver.service << 'EOF'
[Unit]
Description=My Custom Python Web Server
After=network.target

[Service]
Type=simple
User=www-data
WorkingDirectory=/var/www/mysite
ExecStart=/usr/bin/python3 -m http.server 8080
Restart=on-failure
RestartSec=5
StandardOutput=journal
StandardError=journal

[Install]
WantedBy=multi-user.target
EOF

systemctl daemon-reload
systemctl enable --now mywebserver.service
systemctl status mywebserver.service

Palvelutyypit ja prosessin elinkaari

[Service]-osion Type=-direktiivi kertoo systemd:lle, miten seurataan palvelun käynnistymisen valmistumista. Väärän tyypin valitseminen aiheuttaa usein suoritusjärjestykseen liittyviä virheitä.

  • Type=simple — oletus; systemd katsoo palvelun käynnistyneen heti, kun ExecStart käynnistyy. Valmiussignaalia ei tarvita.
  • Type=forking — ExecStart-prosessi haarautuu ja päättyy; varsinainen daemon-prosessi jatkaa aliprosessina. Käyttäkää asetusta PIDFile=, jotta systemd voi seurata sitä.
  • Type=notify — prosessi lähettää ilmoituksen sd_notify(READY=1), kun se on todella valmis. Tämä on luotettavin vaihtoehto monimutkaisille daemoneille.
  • Type=oneshot — suoritetaan kerran ja päättyy; seuraavat yksiköt odottavat valmistumista. Sopii erinomaisesti alustusskripteille.
  • Type=idle — kuten simple, mutta suoritus viivästyy, kunnes kaikki aktiiviset työt ovat päättyneet.
#!/usr/bin/env bash
# Example: oneshot service for a database migration script
# /etc/systemd/system/db-migrate.service

cat > /etc/systemd/system/db-migrate.service << 'EOF'
[Unit]
Description=Run Database Migrations
After=postgresql.service
Requires=postgresql.service

[Service]
Type=oneshot
User=appuser
WorkingDirectory=/opt/myapp
ExecStart=/opt/myapp/scripts/migrate.sh
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target
EOF

systemctl daemon-reload
systemctl start db-migrate.service

Ympäristömuuttujat ja turvallisuuden vahvistaminen

Palveluyksikkötiedostot tukevat useita direktiivejä ympäristömuuttujien välittämiseen ja turvallisuusrajoitusten käyttöönottoon — molemmat ovat tärkeitä tuotantojärjestelmissä.

Ympäristödirektiivit:

  • Environment="KEY=value" — asettaa yhden muuttujan suoraan määritykseen
  • EnvironmentFile=/etc/myapp/env — lataa muuttujat tiedostosta (yksi KEY=value kullakin rivillä)

Yleisiä turvallisuutta vahvistavia direktiivejä:

  • NoNewPrivileges=true — estää prosessia hankkimasta lisäoikeuksia setuid-mekanismin kautta
  • ProtectSystem=strict — liittää hakemistot /usr, /boot ja /etc vain luku -tilaan
  • PrivateTmp=true — antaa palvelulle oman eristetyn /tmp-hakemiston
  • CapabilityBoundingSet= — poistaa käytöstä kaikki Linuxin capability-oikeudet
#!/usr/bin/env bash
# Hardened service unit with environment file

cat > /etc/systemd/system/secureapp.service << 'EOF'
[Unit]
Description=Secure Application Daemon
After=network.target

[Service]
Type=simple
User=secureapp
Group=secureapp
WorkingDirectory=/opt/secureapp
EnvironmentFile=/etc/secureapp/env
ExecStart=/opt/secureapp/bin/server
Restart=on-failure
RestartSec=10

# Security hardening
NoNewPrivileges=true
ProtectSystem=strict
ProtectHome=true
PrivateTmp=true
CapabilityBoundingSet=
ReadWritePaths=/var/lib/secureapp /var/log/secureapp

[Install]
WantedBy=multi-user.target
EOF

# Create the environment file separately so secrets stay out of the unit file
install -m 600 -o secureapp /dev/null /etc/secureapp/env
echo 'APP_PORT=9000' >> /etc/secureapp/env
echo 'DB_URL=postgresql://localhost/mydb' >> /etc/secureapp/env

systemctl daemon-reload

Johdatus systemd-ajastinyksiköihin

systemd-ajastin on yksikkö, joka aktivoi toisen yksikön (yleensä .service-yksikön) aikataulun mukaan. Se korvaa perinteiset cron-työt integroidummalla, lokitettavalla ja hallittavalla mekanismilla.

Jokaiseen ajastinyksikköön (foo.timer) liittyy samanniminen palveluyksikkö (foo.service), joka tekee varsinaisen työn. Käyttöön otetaan ja käynnistetään ajastin, ei palvelua suoraan.

Ajastintyypit:

  • Reaaliaikaiset (kalenteri-)ajastimet — käynnistyvät kellonaikoina käyttäen OnCalendar=-lausekkeita, kuten daily, weekly tai Mon *-*-* 02:00:00
  • Monotoniset ajastimet — käynnistyvät suhteessa järjestelmätapahtumaan käyttäen asetusta OnBootSec=, OnActiveSec= tai OnUnitActiveSec=

Ajastinyksikkötiedoston kirjoittaminen

Rakennetaan täydellinen ajastin- ja palvelupari, joka suorittaa varmuuskopiointiskriptin päivittäin kello 02.00. Huomaatte, että [Timer]-osio on omassa .timer-tiedostossaan, kun taas varsinainen työ määritellään siihen liittyvässä .service-tiedostossa.

Tärkeät [Timer]-direktiivit:

  • OnCalendar= — aikataulun kalenterilauseke
  • Persistent=true — jos järjestelmä oli sammutettuna ajastimen määräaikana, tehtävä suoritetaan heti seuraavan käynnistyksen yhteydessä
  • RandomizedDelaySec= — lisää enintään N sekunnin satunnaisen viiveen, jotta monet samaa aikataulua käyttävät palvelimet eivät kuormita järjestelmää yhtä aikaa
  • Unit= — nimenomaisesti määritetty kohdeyksikkö (valinnainen, jos nimet täsmäävät)
#!/usr/bin/env bash
# Create a daily backup timer pair
# Run as root

# 1. The service that does the work
cat > /etc/systemd/system/daily-backup.service << 'EOF'
[Unit]
Description=Daily Database Backup
After=network.target postgresql.service

[Service]
Type=oneshot
User=backup
ExecStart=/usr/local/bin/backup-db.sh
StandardOutput=journal
StandardError=journal
EOF

# 2. The timer that schedules it
cat > /etc/systemd/system/daily-backup.timer << 'EOF'
[Unit]
Description=Run Daily Database Backup at 02:00

[Timer]
OnCalendar=*-*-* 02:00:00
Persistent=true
RandomizedDelaySec=300

[Install]
WantedBy=timers.target
EOF

systemctl daemon-reload
systemctl enable --now daily-backup.timer

# Verify
systemctl list-timers daily-backup.timer

Lokien tarkasteleminen ja yksiköiden vianmääritys

systemd ohjaa kaiken palveluiden tulosteen journaliin, jota kysellään komennolla journalctl. Tämä kokoaa kaikkien yksiköiden lokit yhteen haettavaan tietovarastoon.

Keskeiset journalctl-valitsimet palveluiden vianmääritykseen:

  • -u <unit> — suodattaa yksikön nimen perusteella
  • -f — seuraa lokia reaaliajassa (kuten tail -f)
  • -n 50 — näyttää vain 50 viimeistä riviä
  • --since "1 hour ago" — rajaa ajan perusteella
  • -p err — näyttää vain virhetasoiset ja sitä vakavammat merkinnät
  • -b — näyttää vain nykyisen käynnistyskerran lokit

Kun yksikön käynnistys epäonnistuu, suorittakaa ensin journalctl -u <unit> -n 30 --no-pager ja sen jälkeen systemctl status <unit>, jotta saatte viimeisimmän virhekontekstin näkyviin.

#!/usr/bin/env bash
# Troubleshooting helper: dump unit status and recent logs
# Usage: ./service-debug.sh <unit-name>

UNIT="${1:-nginx.service}"

echo "=============================="
echo "STATUS: $UNIT"
echo "=============================="
systemctl status "$UNIT" --no-pager -l

echo ""
echo "=============================="
echo "RECENT LOGS (last 50 lines): $UNIT"
echo "=============================="
journalctl -u "$UNIT" -n 50 --no-pager

echo ""
echo "=============================="
echo "ERRORS ONLY (current boot)"
echo "=============================="
journalctl -u "$UNIT" -b -p err --no-pager

Tietotesti: systemd-yksikkötiedostot

Testatkaa ymmärrystänne systemd-palveluiden ja ajastinyksiköiden määrityksestä.

Vastaa interaktiivisessa oppitunnissa

Oppitunnin yhteenveto: systemd-palveluiden hallinta ja yksikkötiedostojen kirjoittaminen

Tässä oppitunnissa tutustuitte systemd-palveluiden hallinnan ja yksikkötiedostojen kirjoittamisen keskeisiin käsitteisiin ammattilaistasolla. Tässä on yhteenveto käsitellyistä aiheista:

  • systemctl-perusteet — start, stop, restart, reload, enable, disable, status, is-active ja is-enabled skripteihin sopivia tarkistuksia varten
  • Luetteloiminen ja suodattaminen — list-units ja list-unit-files sekä valitsimet --type ja --state epäonnistuneiden tai käytössä olevien palveluiden eristämiseen
  • Yksikkötiedoston rakenne — kolme osiota [Unit], [Service] ja [Install] sekä niiden tärkeimmät direktiivit
  • Palvelutyypit — simple, forking, notify ja oneshot sekä kunkin käyttötilanteet
  • Ympäristö ja turvallisuus — EnvironmentFile, NoNewPrivileges, ProtectSystem ja PrivateTmp vahvistettuja daemoneita varten
  • Ajastinyksiköt — .timer- ja .service-tiedostojen yhdistäminen, OnCalendar-lausekkeet ja Persistent-asetuksen avulla tehtävä myöhästyneiden suoritusten käsittely
  • Journalctl — suodattaminen yksikön, ajan, käynnistyskerran ja prioriteetin perusteella vikatilanteiden tehokasta diagnosointia varten

Näillä taidoilla voitte hallita mitä tahansa järjestelmäpalvelua, ajoittaa toistuvia tehtäviä luotettavasti ja kirjoittaa tuotantokelpoisia yksikkötiedostoja omille daemoneillenne.

Aloita maksutta

Opi Bash tekoälytuutorin avulla — ilmaiseksi

Kirjoita ja suorita oikeaa koodia selaimessa, saa välitöntä apua tekoälytuutorilta ympäri vuorokauden ja jatka siitä, mihin jäit, verkossa tai sovelluksessa.

Kurssit
22
Oppitunnit
88
Aloita opiskelu maksuttaNäytä koko kurssi

Usein kysytyt kysymykset

Onko oppitunti ”systemd-palveluiden hallinta ja unit-tiedostojen kirjoittaminen” ilmainen?

Kyllä – oppitunnin ”systemd-palveluiden hallinta ja unit-tiedostojen kirjoittaminen” koko tekstin voi lukea täällä verkossa ilmaiseksi. Jos haluat harjoitella interaktiivisesti sisäänrakennetulla koodieditorilla ja ympäri vuorokauden käytettävissä olevan tekoälytuutorin avulla sekä avata koko Linux-komentorivin ja Bash-komentosarjojen hallinta-kurssin, päivitä CoddyKit PROhon. Linux-komentorivin ja Bash-komentosarjojen hallinta-kurssilla on yhteensä 4 oppituntia.

Mitä opin oppitunnilla ”systemd-palveluiden hallinta ja unit-tiedostojen kirjoittaminen”?

Ohjaa palveluita systemctlillä ja kirjoita mukautettuja unit- ja ajastintiedostoja skriptattaville daemon-palveluille. Harjoittelet Linux-komentorivin ja Bash-komentosarjojen hallinta-aihetta koodilla, jonka suoritat suoraan selaimessa. Ympäri vuorokauden käytettävissä oleva tekoälytuutori vastaa kysymyksiisi oppitunnin aikana.

Tarvitsenko kokemusta aloittaakseni Linux-komentorivin ja Bash-komentosarjojen hallinta-opiskelun?

Aiempi kokemus ei ole tarpeen. CoddyKitin Linux-komentorivin ja Bash-komentosarjojen hallinta-oppimispolku sopii vasta-alkajista edistyneisiin, joten voit aloittaa tästä tai alusta ja edetä omaan tahtiisi. Tämä on oppitunti 2/4.

Kuinka kauan ”systemd-palveluiden hallinta ja unit-tiedostojen kirjoittaminen”-oppitunnin suorittaminen kestää?

Useimmat CoddyKitin oppitunnit kestävät noin 5–10 minuuttia. Jokainen oppitunti on lyhyt ja interaktiivinen, joten edistyt tasaisesti ja voit jatkaa siitä, mihin jäit – sekä verkossa että sovelluksessa.

Voinko kirjoittaa ja suorittaa koodia tällä Linux-komentorivin ja Bash-komentosarjojen hallinta-oppitunnilla?

Kyllä. Jokainen Linux-komentorivin ja Bash-komentosarjojen hallinta-oppitunti sisältää sisäänrakennetun koodieditorin, joten voit kirjoittaa ja suorittaa oikeaa koodia suoraan selaimessa ja saada välitöntä palautetta tekoälyltä – paikallista asennusta ei tarvita.

Kaikki tämän kurssin oppitunnit

  1. Käyttäjien ja ryhmien luonnin automatisointi
  2. systemd-palveluiden hallinta ja unit-tiedostojen kirjoittaminen
  3. Levyjen, tiedostojärjestelmien ja liitosten automatisointi
  4. Järjestelmän kuntotarkistus- ja hälytysskriptien rakentaminen
← Takaisin: Linux-komentorivin ja Bash-komentosarjojen hallinta