Egy xrdp szervert (már nem az első) akarok beállítani (xfce4), és néhány folyamatot nem akarok futtatni, mert nincs rájuk szükség, pl.: alsa-utils, cups, lightdm. (hang nem kell, nyomtatásra nincs igény, a kiszolgálón meg felesleges beindítani az Xwindow felületet).
A probléma az, hogy hiába kapcsolom ki ezeket (update-rc.d [script] disable és update-rc.d [script] remove ), újra indításkor ugyanúgy betöltődnek. Ezért egy faék stupid megoldást csináltam: a folyamatokhoz tartozó .service fájlokat átneveztem a /lib/systemd/system könyvtár alatt, így aztán nem töltődnek be a rendszer indításakor.
Az érdekes a dologban az, hogy csak 16.10-es telepítéseknél csinálja ezt, 16.04-esnél valamint annak 16.10-re upgradelt verziónál nem mutatkozik ez a hiba.
Sok próbát csináltam, VirtualBox lehetőségeit kihasználva 5 féle telepítést is csináltam, és ezeknél is a fent vázolt eredmények jöttek ki.
Valaki találkozott már a problémával?
Hozzászólások
Ha systemd, akkor általában
systemctl stop valami.service
systemctl disable valami.service
De ettől még függőségként elindulhat az adott service. Ha azt szeretnéd, hogy semmiképp se induljon, akkor
systemctl mask valami.service
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Köszönöm az ötletet. Azonban nem jártam sikerrel, mert ugyanúgy betöltődnek újraindításkor.
Ugye itt most systemd unit file-okról beszélünk, s nem shell scriptekről? Mert ha ez utóbbiról, akkor azt bármi elindíthatja. A systemd viszont a unit file-okat manageli. Maszkoltad, s úgyis elindult?
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
pontosan: systemd unit file-okról van szó, és ezek után is elindulnak. De hangsúlyozom: csak frissen telepített 16.10 alatt van ez a jelenség.
Hirtelen az az érzésem, több helyről van hivatkozás. Elég nehezen tudom elképzelni, hogy ha egy symlink a /dev/null-ra mutat, akkor hogyan is indul valami el. Egész egyszerűen fizikailag nem tudná megtalálni. Valaki variált - persze lehet a disztribútor is, aki bugot írt bele -, hiszen a systemd több helyről is indítja a unit file-okat. Szerintem az egyik helyen maszkolva lett, de lehet még érvényes hivatkozás máshol. Itt vannak a lehetséges elérési utak, ezeket nézd át:
https://www.freedesktop.org/software/systemd/man/systemd.unit.html
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Köszönöm, utána járok a dolognak.
Egyelőre beraktam egy scriptet ami legutoljára indul el, és ez leállítja a nem kívánt folyamatokat. Ez is egy faék egyszerű megoldás (habár nem a legelegánsabb), de a frissítések során nem fog probléma adódni.
Inkább egy systemctl status-szal nézd meg, hogy hol találta meg a unit fájlt.
BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)
+1
Mivel már nem tudom szerkeszteni: vagy mondd meg, hogy mi nem indul el, és akkor bele tudunk nézni a csomagba, hogy mi az és hogyan indulhat el mégis.
BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)
Nagyon faék és az első updatekor fog eltörni. Azokat ugyanis az upstream/disztró szállítja, és a contract, hogy nem piszkálod, vagy ha igen, a csomagkezelő bármikor felülcsaphatja - cserébe teljesen maszkolhatod őket (/etc/systemd/system/foo.service néven létrehozol egy fájlt, akkor csak annak a tartalmát nézi - és pl. symlinkelheted ilyen néven a /dev/null-t, akkor soha nem fog elindulni a service; ezt csinálja a fentebb írt systemctl mask), vagy kiegészítheted egy /etc/systemd/system/foo.service.d/ könyvtárba pakold fájlokkal, amiket értelmezni fog az upstream service fájl után.
BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)