Sziasztok!
Külső HDD-re kell időnként backupot csinálni, ennek automatizálására úgy gondoltam hogy tök jó lesz az udev event, indít egy scriptet, csatol, backupol, leválaszt, és nem kell kézzel semmit sem csinálni.
Ehhez képest tök megbízhatatlan az egész.... Néha triggerelődik az esemény, néha meg nem. Egyáltalán nem determinisztikus. Több diszk van, kétféle méretben (4 és 8TB, 5-5db), Seagate USB külső HDD-k, mondanám hogy működés szempontjából teljesen mindegy, de nem.
A 4T-os többnyire mennek és indulnak automatán amikor csatlakoztatják a diszket. Talán 1 ami nem. A 8T-sokból viszont egy sem indul, vagy max 1. 10x leellenőriztem az UUID-t, hogy stimmel-e. Volt amelyiken már újrakreáltam a GPT-t, a partíciót, a luks-ot, mindent, semmi nem változott.
A működés az (lenne), hogy az udev triggerelt esemény elindít egy systemd unitot, paraméterben az uuid-vel, ami egy sima simple unit, elindít egy scriptet szintén a diszk uuid-jével, ami majd tudja hogy melyikre mit kell syncelni. De ez mindegy is, mert idáig nem jutunk el.
Szóval a lényeg:
cat 2712c798-7f3a-4884-b394-244aa6dacf37.rules ACTION=="add", SUBSYSTEM=="block", ATTR{partition}=="1", ENV{ID_FS_UUID}=="2712c798-7f3a-4884-b394-244aa6dacf37", RUN+="/usr/bin/systemctl start backupstart@$env{ID_FS_UUID}"
Csak az UUID más természetesen, illetve ezzel korrelálva a fájlnév, de ez működés szempontjából mindegy.
Próbáltam már csűrni-csavarni, igazából semmi változást nem értem el - pár diszk megy, pár meg nem. Talán annyi, hogy azok a diszkek, amik indulnak automatán, azok mindig, amik meg nem, azok sosem, de erre nem esküszöm meg, lehet csak a véletlen műve.
Ha belépek minden esetben látszik a diszk, a megfelelő uuid-jű partíció, akkor is ha az udev nem indította, kézzel elindítva systemctl start backupstart@akarmi lefut rendben, szóval a rossz a diszk, nem jó az usb port és hasonlók is kizárható.
Ötleteket várok: mit csináljak vele?
Hozzászólások
Hát ez nem sok.... :(
"Sose a gép a hülye."
egy egyszeru teszt ha a systemd-s izet lecsereled egy sima scritpre ami beleechozza, hogy "hallo itt vagyok $UUID" egy allomnyba es megnezed hogy az mukodik e. Ha mukodik, akkor a systemd-nel keresnem a bajt. ha nem, akkor kerdes, miert nem inditja el az udev a scriptedet es akkor ezt kell megjavitani. Bar nalam meg sosem fordult elo, hogy az udev ne tudott volna lefuttatni egy scripet (igaz nincs systemctl-es szarakodas sehol :D).
Amugy a csodas binaryfuckofflogging journalctl mit mond? Egyaltalan megfuttatja a systemctl unitot a systemd?
"Nem futtatja meg", ez a baj.
"Sose a gép a hülye."
csinald maskent, mondjuk cronbol
ha latod az uuid-t indits egy backupot ami azzal kezdi hogy ha nincs csinal egy lockot es backupol ha van akkor nem csinal semmit
ha nem latod az uuid-t vedd le a lockot
neked aztan fura humorod van...
hat ahogy erzem itt midnenaron systemd-siteni akar a kollega, szoval timeunit lesz az :D
Ha más nem lesz, akkor igen, marad egy ilyen paraszt megoldás.
"Sose a gép a hülye."
A legtöbb rendszer már automatikusan csatolja a bedugott eszközt - nem elképzelhető, hogy ezzel az automatikával "akad össze" a te megoldásod?
A "Néha triggerelődik az esemény, néha meg nem. Egyáltalán nem determinisztikus." és a "alán annyi, hogy azok a diszkek, amik indulnak automatán, azok mindig, amik meg nem, azok sosem," nekem kicsit ellentmondásosnak tűnik.
Javaslok némi debugolást is: ne rögtön a systemctl-t indítsd, hanem a saját scriptedet, ami a /tmp alá rögtön lelogolja, hogy elindult, milyen paramétereket kapott, majd elindítja a systemct programot, de annak a kimenetét is fájlba tolja, stb.
Nem csatol semmit automatikusan.
A script küld emailt ha elindul, és akkor is ha végez. Innen tudjuk, hogy nem indul el az esemény. És ilyenkor a systemd unitnál sem látszódik semmi, tehát az udev nem lövi el az eseményt.
"Sose a gép a hülye."
Szóval ha a systems ize nem küld mailt mert nem indul el, akkor tuti az udev a hibás.
Mások is írták, mi lenne ha nem systemd unit indulna hanem script? Ha az mindig elindul, akkor lehet tovább debuggolni, hogy egyes esetekben miért nem indul a systemd unit.
De addig csak azt hajtogatjuk körbe és körbe, hogy mer az udev nem indiccsa és ez a baj. Ez messze van a hibakeresestől.
Az ötlet nem újkeletű, régebben is használtam ugyanígy, igaz más rendszerrel és pendrive-okkal, de az is systemd votl már. Mivel sokáig fut a a backupt script, volt hogy az udev timeoutolt és lelőtte az általa indított scriptet, ezért lett a systemd-vel indítva, plusz így a systemdben látszik a script kimene is.
Mivel ilyenre (systemd indít egy darab scriptet) több más működő dolog is van, illetve ha kézzel indítom is mindig elindul, így nem gondolnám hogy ezzel van a hiba.
Elég sokat debuggolok és elég jó vagyok a hibakeresésben úgy általában, van hogy 10 perc alatt megoldom azt, amit más 1 nap alatt se, ami szerintem annak köszönhető, hogy nem indulok el a szélrózsa minden irányába és nem vakvágányokon megyek mint mások és cseszem el az időt, hanem végiggondolom és logikusan végignézem, kizárok dolgokat, úgyhogy egyelőre ez irányba nem mennék. Ha nincs más ötlet és minden mást kilőttem és még mindig nem megy, akkor majd megyek erre.
"Sose a gép a hülye."
Ne haragudj de nem minositettelek, csak megallapitottam, hogy a retegeket tesztelve egyesevel ugy hogy minimal dolkokat hasznalunk az egyes retegekben neha azonnal kidobja a hibas layert.
Elhiszem, hogy te nem gondolod hogy ezzel van a hiba. Es a tesztek ezt (gondolom) be is bizonyitottak?
Semmi esetre sem akartalak leszolni. De engedd meg nekem hogy tovabbra is ugy gondljam, hogy az egyes retegeken egyesevel alulrol-felfele elindulva nem a szelrozsa minden iranya.
Pontosan ezt próbálom csinálni, amíg az udev nem lövi el az eventet, addig totálisan mindegy, hogy a script vagy a systemd mit és hogy csinál.
Autós példával élve (mert hát ez félig egy autós portál), ha nem indul az autód, hiába cserélsz fékolajat meg akasztasz be egy wunderbaum-ot, attól még nem fog beindulni. Én ezt látom.
"Sose a gép a hülye."
Én értem, hogy a script küld emailt, ha elindul, de tudjuk hogy nem indul el és ha jól értem, akkor az is megvan, hogy a systemd sem indul el.
De én nem azt kértem, hogy a nem induló scriptet debugold, én azt kértem, hogy azt a scriptet, amit az udev futtat és amiből a systemd-nek indulnia kéne, azt debugold. Tehát ahogy fentebb is írtam: az udev ne systemctl-lel szórakozzon, hanem mezei bash scriptet indítson, az naplózza le, hogy elindították, hogy milyen paramétereket kapott, majd indítsa el a systemctl parancsot, de annak a kimenetét is (a standarderrort is(!)) szintén naplózza le.
Sötétben tapogatózás, de: ha adsz a rules fájl nevéhez egy 90- prefixet, hogy biztosan utoljára fusson, akkor sem?
https://www.suse.com/support/kb/doc/?id=000016106
BlackY
"Gyakran hasznos ugyanis, ha számlálni tudjuk, hányszor futott le már egy végtelenciklus." (haroldking)
Köszi, teszünk egy próbát, átnevezem őket.
Update: Nem változott semmi. Tegnap rádugtak egy 4 és a 8T diszket, a 4-es elindult, a 8-as nem.
"Sose a gép a hülye."
A lenti alapján (hogy most már működik): az átnevezés után újratöltetted a szabályokat (udevadm control --reload-rules vagy valami ilyesmi, vagy reboot :) )?
BlackY
"Gyakran hasznos ugyanis, ha számlálni tudjuk, hányszor futott le már egy végtelenciklus." (haroldking)
ha mar van systemd-d, akkor ez azzal csinalnam. systemctl -a, keresd meg a megfelelo foo.device-t, arra mar tudsz dependelni. akar egy .mount unittal, aztan egy .service unittal. probald lemasolni hogy csinalja a systemd-fsck@.service
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
Jó ötlet. Egyelőre ez a 90-es prefix bekerült, hétfőn délelőtt kiderül, hogy segít-e, ha nem, akkor átpakolom az egészet systemd-re.
Update: Megnéztem, így hirtelen egyetlen kérdésem van, a pucér UUID-re hogy lehet hivatkozni a unitban? Ez alapján dönti el a script, hogy a diszk mihez tartozik és hogy mit kell rá syncelni... Ha másképp nem megy, parasztban a script elején le tudom szedni a "dev-disk-by-uuid-" prefixet... De szebb lenne ha oda se kerülne. :)
"Sose a gép a hülye."
systemdfsck-ban ez van:
Description=File System Check on %f
ez lesz: File System Check on /dev/disk/by-uuid/e45988da-54f3-424c-b26e-28e864d454
ebbol a script mar ki tudja banyaszni, sot figyelni is tud ha nem uuid-es dev-et kap valami magic folytan.
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
Az én megoldásom incrond lenne erre, a /dev/disk/by-uuid/ könyvtárban a változásra (IN_CREATE) elindul script és megcsinálja amit kell. Letesztelem, 20-ból 20x működött.
amelyik nem indul el, arre udevadm test /sys/block/sdx1 es udevadm info -a /dev/sdx1 matchel a ruleoddal?
Rádugtak most egy 8T-sat, természetesen Murphy már felkelt, úgyhogy működik (magától elindult a mentés is).
"Sose a gép a hülye."
Lement a mentés. Szóltam hogy tegyenek rá másikat. Természetesen most megy ez is.
"Sose a gép a hülye."