Adott user-rel nem futó program (daemon) (megoldva, más hiba okozta)

Linux-haladó

Sziasztok.
Van egy hálózatmonitorozó programom, amit egy rendszer user alatt kell(ene) futtatni (https://github.com/csikfer/lanview2 -ből az lv2d program).
Van két Ubuntu 16.04.1 szerver. Az egyik egy régebbi darab, frissítve lett 14.04-röl, a második egy frissen telepített 16.04.1. Még annyi a különbség, hogy az elsőn lefordítható a project, a másikon nincs fordító, oda a lefordított binárist csak átmásoltam.
Tehát van egy lanview2 user 1000 alatti ID-vel. És ez alatt fut az lv2d, ami a lekérdezéseket futtatja. Az első szerveren működik. A frissen telepítetten pedig nem. Ha elindítom root-ként, akkor teszi a dolgát, ha elindítom a saját bejelentkezésem alatt, akkor is. Ha a lanview2 user alatt indítom, akkor szó nélkül visszaadja a promptot. Nem ír ki semmit, a main függvény első sora egy printf, tehát a main függvény sem hívódik meg. A kilépési kód 8. Nem meglepő módon a systemd sem tudja elindítani a programot (a másik szerveren így indul).
Az első szerveren a /etc/passwd sor :
lanview2:x:108:65534::/var/local/lanview2:/bin/false
A másikon (amin nem működik):
lanview2:x:113:65534::/var/local/lanview2:/bin/false
Különbség, még, hogy a második szerveren van lanview2 group is, aminek a lanview2 user a tagja, mert ehhez a tagsághoz van engedélyezve egy setuid-s program (nagios plugin) indítása.
Miért nem lehet elindítani a programot a megadott user-rel?

  • 2845 megtekintés

( wachag | 2016. 10. 09., v – 10:35 )

Egy strace és egy ltrace kimenetet felraksz pastebin-re? Kíváncsivá tettél.

Jó hogy megnéztem még egyszer. Ott van az strace kimenetben a main() első sora által kiírt sor, tehát mégiscsak indul a main(), valószínűleg a következő sorban lép ki, ami a Qt initje.
Mégjobban átnézve kiderült, hogy a konfig-ban rosszul van megadva a home könyvtár, vagyis én csesztem el, és azért nem indul a program.
Egy dolgot azért nem értek. Az strace végén van az a kiírás, ami a main() első sora. Időben ezután van a Qt init, és valahol utána hozom létre a QSet objektumot, ami a hibás konfig állományt kezeli. Az strace-ban pedig a hibásan megadott könyvtár neve előbb szerepel, a hibás könyvtárnév nem igazán származhat máshonnan, min a konfig állományból.
Kijavítottam, fut a program.

Munka könyvtár a helyes kifejezés, ami nem mindig azonos a $HOME-val, ha pl. én futtatom tesztelési céllal, vagy debug-olom.
Engem az érdekelne, hogy nem írt ki semmit a konzolra, miközben leellenőriz mindent, most megnéztem a kilépési kód stimmel (8 = nincs ilyen mappa). A program jellemzően mindig telefossa a konzolt nyomkövetési üzenetekkel, ezek most hova lettek? (Átírtam itthon a konfigot, hibás mappa névre. Az otthoni gépemen nincs feltöltött adatbázis, ezért nálam egy sorral előbb hibára fut, mégis kiír a konzolra kb. 20 sort.)
Miért nem időrendi sorrendben jelennek meg a műveletek az strace kimenetén?

ui.: Fentebb azt írtam, hogy az ini fájlt a QSet osztály dolgozza fel, elírta, a QSetting az osztály rendes neve.

Örülök, hogy megoldódott.

Valszeg a HOME könyvtár kezelés úgy történt, hogy kész volt a progi, a $HOME-ba írt. Majd valaki kitalálta, hogy írhasson közös könyvtárba is, mert akkor többen tudnak dolgozni rajta (akkor mire kell az adatbázis?). Ezt is beleépítették, de akkor már nem-ért-rá/nem-dolgozott-ott/nem-vette-komolyan az, aki a szép logolást beépítette.

Tanultunk belőle, köszi!

A programot én írom egyedül, már több éve, és szívesen dolgoznék együtt másokkal, de a project még nem ütötte meg senkinek sem az ingerküszöbét. Bár a főnököm már belátta, hogy nagyon hasznos lenne, ha működne, elvileg támogat is, de csak elvileg.
A loggolás teljesen jól működik (a fenti esetet kivéve), mindig ügyeltem, hogy minden le legyen ellenőrizve, és erről legyen log is. Olyan szokott lenni, hogy többször írja ki ugyanazt, vagy elveszik a lényeg a sok szövegben, de hogy semmi, ez az első eset. Szóval nem értem (és így túl sokat nem is tanultam belőle).
A program "tennivalója" az adatbázisban van, anélkül nem tud csinálni semmit. Még a GUI által megjelenített formok is az adatbázisban vannak, egy két egyedi ablak kivételével. (A most problémás modulban nincs GUI, az egy daemon ami most konkrétan a DHCP szervereket monitorozza).

Én inkább azt értettem ki belőle, hogy a Qt-n belül zavargott valami, és azt nem kezelte le. Az, hogy az strace-t ltrace-t nem ismerte/nem jutott eszébe, az előfordulhat. Linux alól meg C++-t debuggolni - ha olyan körülmények közt nőttél fel - elég kényelmetlen tud lenni, ha nem ismered a lehetőségeket.

Bakker, te bele is néztél a programba (csak kb. 50 000 sor), vagy végigolvastad az egész szálat, hogy ilyen okos vagy?
Azon a szerveren, ahol a hiba jelentkezett még fordító sincs, így debugolni is viszonylag nehéz. A program rengeteg nyomkövetési infót ír ki, így nagyon nem világos, hogy most miért nem írt ki semmit. Az az egy printf sor később került bele, miután nem értettem mi történt, aztán figyelmetlen voltam, és nem vettem észre a nyomát az strace-ban (fura helyen), az ltrace-t tényleg nem ismerem.
Szóval, továbbra sem világos miért nem voltak nyomkövetési üzenetek, miért vannak az strace-ban időrendtől eltérő sorrendben a nyomkövetési üzenetek. Nem hiszem, hogy én vagyok az első fórumozó, aki rossz megfigyelésből levont egy rossz következtetést, így rossz helyen kereste a hibát. Elismerem nem értek mindenhez, de ha volt energia a fikázásra, akkor illene a magyarázatra is, ha nincs magyarázat, akkor a fikázást is hanyagolni kéne.

Az esetből azt lehet megtanulni, hogy egy kettős hiba hihetetten hatékonysággal tudja az embert bevinni az erdőbe, ahol aztán menthetetlenül eltéved (én ezt eddig is tudtam, csak megerősítést nyert, sokadszorra ).
A konfigurációs hiba mellé volt egy log/nyomkövetési hiba is. Régen belekerült a log rendszerbe egy plusz feltétel, ami nem lett követve az alapértékek beállításánál. Így ha hiba azelőtt lépett fel, hogy a log rendszer inicializálva lett volna, nem minden esetben lettek log-olva a hibák. Persze, amikor direkt csináltam egy korai hibát, akkor az ki lett írva, csak ez az ominózus hiba nem.
Amikor réges régen programozást tanultam (algolt, meg fortrant), a tanárnak volt egy mondása: "Egy kis programban triviális, hiba nincsen. Egy nagy programban triviális hiba nincsen."
Arra senki nem tippelt, hogy miért van időrendben rossz helyen egy printf kiírás. Gondolom az lehet az oka, hogy az stdout-ra kiírás pufferel, bár emlékeim szerint az '\n' implicit csinál egy flush-t, de nem ez lenne az első eset, hogy évtizedek távolságában rosszul emlékszem valamire.