Tartalom

Bevezető

A Linux szolgáltatások háttérben futó programok, amik nem rendelkeznek külön kezelőfelülettel, hanem valamilyen kommunikációs mechanizmuson keresztül (többnyire a hálózaton) válaszolnak más programok kéréseire. Ezek egy részét - működésüktől függően - daemon-nak hívják. A szolgáltatásokat a modern Linux rendszerekben a systemd menedzseli, és a systemctl parancs segítségével lehet őket elindítani, leállítani, stb.

A systemctl parancs a szolgáltatások elindításán és leállításán kívül még számos funkciót tartalmaz, mint például a szolgáltatások letiltása, engedélyezése, maszkolása vagy felfedése (unmask), stb. Ebben a rövid hibaelhárítóban a maszkolással és felfedéssel foglalkozunk. Hogy jobban megértsük magát a problémát, ejtenünk kell röviden néhány szót magáról a maszkolásról is.

Szolgáltatások maszkolása, felfedése (unmask)

A szolgáltatások maszkolása a szolgáltatások letiltásának egy másik módja. A különbség annyi, hogy míg a letiltás esetén a szolgáltatáshoz tartozó összes szimbolikus linket eltávolítja a rendszer, addig a maszkolás esetén ezek a szimbolikus linkek a /dev/null elemre mutatnak. Ha egyszerűen letiltunk egy szolgáltatást, az továbbra is manuálisan indítható marad. Amikor pedig maszkolunk egy szolgáltatást, azt nem lehet manuálisan elindítani. Más szóval, a maszkolás végleg használhatatlanná teszi a szolgáltatást, amíg fel nem fedik azt újra.

A szolgáltatások letiltása és engedélyezése az alábbi parancsokkal történik:

sudo systemctl disable <unit név>
sudo systemctl enable <unit név>

A maszkolás és felfedés pedig:

sudo systemctl mask <unit név>
sudo systemctl unmask <unit név>

A maszkolásnak biztonsági vonatkozásai vannak, ugyanis egy szolgáltatást nem csak kézzel lehet elindítani, hanem más programok, szolgáltatások is elindíthatják őket a háttérben valamilyen események hatására, stb. Ha átmenetileg használaton kívül szeretnénk helyezni egy szolgáltatást, hogy semmi ne tudja elindítani azt, akkor a maszkolás a jó megoldás erre.

Most, hogy érintőlegesen ejtettünk erről néhány szót, térjünk is rá a hibajelenségre és annak a megoldására.

A hibajelenség

Egy szolgáltatást a rendszer maszkolt, amit a systemctl unmask paranccsal nem lehet feloldani. A parancs nem dob hibát, de nem is hajtja végre az unmask műveletet.

A saját példámban az ily módon "beragadt" szolgáltatás a Chrome Remote Desktop volt, aminek segítségével távirányíthatunk másik számítógépeket az asztalon keresztül.

Amikor kijön egy frissítés a csomaghoz, akkor időnként előfordul nálam, hogy nem indul elsőre megfelelően a távirányítás. Ez olyankor szokott előfordulni, amikor módosul a /opt/google/chrome-remote-desktop/chrome-remote-desktop fájl, amit a fentebb linkelt leírásnak megfelelően kézzel kellett módosítani, hogy a távirányító az aktuális munkamenetre kapcsolódjon, és ne egy üres asztalt kapjunk egy új munkamenetben.

Amikor ilyen történik, akkor újra elvégzem a módosításokat a fájlon, amihez le kell állítani a Chrome Remote Desktop szolgáltatását, és újra kell indítani azt, hogy érvénybe léphessenek a módosítások. És ilyenkor szokott jönni a hiba: Amikor kiadom az alábbi újraindító vagy elindító parancsok bármelyikét:

systemctl restart chrome-remote-desktop
systemctl start chrome-remote-desktop

Az alábbi hibaüzeneteket kapom:

Failed to restart chrome-remote-desktop.service: Unit chrome-remote-desktop.service is masked.
Failed to start chrome-remote-desktop.service: Unit chrome-remote-desktop.service is masked.

A dolog idáig világos: a Chrome Remote Desktop szolgáltatása maszkolva van, ezért nem lehet sem elindítani, sem újraindítani, hiszen nem is megy. Ha lekérdezem a szolgáltatás állapotát:

systemctl status chrome-remote-desktop

Akkor írja is, hogy inaktív, mert maszkolva van:

● chrome-remote-desktop.service
   Loaded: masked (Reason: Unit chrome-remote-desktop.service is masked.)
   Active: inactive (dead)

Ilyenkor nálam nem is érhető el az érintett számítógép, ami jelen esetben a "Laptop 1 - Debian10" névre hallgat:

A listában szürkével jelenik meg inaktívként.

Ez idáig még rendben is volna, mert normál esetben egy másik szolgáltatáspéldány működteti a megfelelő munkamenetet a megfelelő felhasználó nevében, viszont a fő szolgáltatást újra kell indítani ha módosítjuk a fentebb említett fájlt, hogy a távirányító programban érvénybe lépjenek az új beállítások.

A hiba tehát itt kezdődik, hogy hiába futtatom a systemctl unmask parancsot, ebben az esetben hatástalan. Tehát a parancs segítségével nem lehet feloldani a szolgáltatást.

A következő fejezetben megnézzük erre a megoldást.

A megoldás

Amikor a megfelelő parancsokkal nem lehet feloldani a maszkolt szolgáltatásokat, akkor manuálisan is megoldhatjuk az ilyen problémát. Természetesen root-ként hajtsuk végre a további részeket is. Lépjünk be a /lib/systemd/system könyvtárba:

cd /lib/systemd/system

Majd itt keressünk rá a kérdéses szolgáltatás nevére. A saját példámban a "chrome" szóra keresek rá:

Itt megtaláljuk a szolgáltatáshoz kapcsolódó unit fájlokat, amint azok a /dev/null -ra mutató szimbolikus linkek. Ebben a példában csak egy unit fájl van ilyen, de más szolgáltatás esetében lehet több is. Továbbá még találunk itt egy "@.service" végződésű fájlt is, amire mindjárt ki is térünk. Ezeket a /dev/null/ -ra mutató szimbolikus linkeket töröljük az unlink parancs segítségével:

unlink chrome-remote-desktop.service

Természetesen a saját szolgáltatásunk fájljait töröljük, amiket nem sikerül feloldanunk az unlink opcióval.

Ezután engedélyezzük a szolgáltatást a már fentebb bemutatott paranccsal:

systemctl enable chrome-remote-desktop@.service

Miután engedélyeztük a szolgáltatást és az esetleges további szolgáltatáspéldányokat, indítsuk el, majd ellenőrizzük:

systemctl start chrome-remote-desktop.service
systemctl status chrome-remote-desktop.service

Itt tehát látható maga a fő szolgáltatás, amint fut.

Valamint érdekességképpen még ránézhetünk az említett példányosított szolgáltatásra, ami ez esetben a saját felhasználómhoz kapcsolódó gyermekszolgáltatás: 

systemctl status chrome-remote-desktop@botond.service

● chrome-remote-desktop@botond.service - Chrome Remote Desktop instance for botond
   Loaded: loaded (/lib/systemd/system/chrome-remote-desktop@.service; enabled; vendor preset: enabled)
   Active: active (running) since Tue 2022-08-16 02:47:52 CEST; 1h 49min ago
 Main PID: 1387 (chrome-remote-d)
    Tasks: 0 (limit: 4052)
   Memory: 308.0K
   CGroup: /system.slice/system-chrome\x2dremote\x2ddesktop.slice/chrome-remote-desktop@botond.service
           ‣ 1387 /usr/bin/python3 /opt/google/chrome-remote-desktop/chrome-remote-desktop --child-process --config=/home/botond/.conf

aug 16 02:47:52 laptop systemd[1]: Stopped Chrome Remote Desktop instance for botond.
aug 16 02:47:52 laptop systemd[1]: Started Chrome Remote Desktop instance for botond.
aug 16 02:47:52 laptop systemd[1387]: pam_unix(chrome-remote-desktop:session): session opened for user botond by (uid=0)

(itt eltérnek a futási idők, mert több részletben készítettem a leírást, és közben többször leállítottam, illetve újraindítottam a gépet)

Eredmények ellenőrzése

Végül ellenőrizhetjük a munkánk eredményét:

A Laptop újra elérhető, mint korábban, a számítógép frissítése előtt. És a csatlakozás is működik:

Tehát a távirányítás is hibátlanul működik.

A gép következő újraindítása után a fő szolgáltatás ismét maszkolásra vagy tiltásra fog kerülni a program által, de ez a távirányító program normális működésének a része. Később már nem okoz újból problémát, mivel a konfigurációs fájlt már nem kell módosítani, valamint a példányosított szolgáltatás továbbra is futni fog, ami kezeli a felhasználóhoz kapcsolódó munkamenetet, ezzel biztosítva, hogy a konfigurációs beállításoknak megfelelően a felhasználó grafikus munkamenetére csatlakozzon a távirányító program.

Konklúzió

A saját példámban ez egy ritkán, de azért előforduló jelenség, amikor frissül a Chrome Remote Desktop csomag, és a konfigurációs fájlt is érinti a frissítés, ilyenkor újra beállítom a saját módosításaimat a fájlon, majd kézzel feloldom a szolgáltatás maszkolását, és újra engedélyezem. Ezután a program ismét zavartalanul működik sokáig.

Ez természetesen egy konkrét, egyedi példája volt egy maszkolt szolgáltatás kézi feloldásának, de a folyamat bemutatására kiválóan alkalmas. Ettől eltérő szolgáltatások esetén is hasonló módon járhatunk el, amennyiben az erre szolgáló systemctl parancs unmask opciója valamilyen okból nem birkózik meg a feladattal.