Dotaz: uids a udevd

[pht]

pred par dny jsem upgradoval jadro na jednom stroji a myslim ze jsem zapnul takovou tu feature ktera rozdeluje cpu cas podle uid procesu (nasledujici problem muze a nemusi s tim souviset).

problem: na stroji vznika pomerne hodne procesu s ruznymi uid (to neovlivnim - server pro mnoho uzivatelu). na zaklade toho vznikaji a zanikaji adresare typu /sys/kernel/uids/uid. pri kazdym takovym vzniku a zaniku se vygeneruje event pro udevd, kterej na zaklade toho pusti obsluzne skripty, viz kus strace:

execve("/sbin/udev", ["udev", "uids"], ["ACTION=remove",
 "DEVPATH=/kernel/uids/100000114", "SUBSYSTEM=uids",
 "SEQNUM=1905123", "HOME=/",
 "PATH=/sbin:/bin:/usr/sbin:/usr/bin", "UDEVD_EVENT=1"]

toto se deje hodne casto a stroj to nestiha, tudiz udev zere hodne % cpu, pripadne vznika hodne (10000+) procesu s eventama (typu /sbin/udevsend uids).

zkousel jsem s tim ruzne cvicit ale zda se ze nic nezabralo. zkusil jsem do udev rules pridat radek:

SUBSYSTEM="uids", OPTIONS="ignore_device"

ale zda se ze to nema vliv. navic je divne ze v strace snipetu je SUBSYSTEM=uids, zatim co kdyz se na to divam pres udevinfo tak mi pise SUBSYSTEM=unknown. zkousel jsem udevd i zabit, ale z nejakeho duvodu se hned po zabiti vrati (to je dalsi otazka: kde se furt bere, v inittab neni a zadnej pousteci skript taky nema. leda by to hlidal kernel, ale to mi prijde dost prasarna)

takze co s tim? musim rict ze streva udev moc neznam a na netu take neni o tom moc informaci.

Odpovědi

[pht]

tak nakonec jsem to vyresil odstranenim te feature -- GROUP_SCHED -- z jadra, jine reseni neznam (mozna upgradnout udev?). a jak presne udev funguje je mi stale zahadou.

[hanzelko]

a co takto

SUBSYSTEM="uids", OPTIONS+="ignore_device"

[hanzelko]

a co takto

SUBSYSTEM=="uids", OPTIONS+="ignore_device"

[petr_p]

Nevím jak u vás, ale u mě je udev démon, který poslouchá na několika deskriptorech:

udevd   968 root    3r   DIR        0,8       0       1 inotify
udevd   968 root    4u  unix 0xd70b5de0             150 socket
udevd   968 root    5u  sock        0,4             151 can't identify protocol
udevd   968 root    6r  FIFO        0,5             152 pipe

Konkrétně hlídá změny souborů přes inotify (to asi bude váš případ změn v proc), pak přes NETLINK socket hovoří s jádrem (tudy dostává informace o hardwaru) a pak tu je UNIX socket pro komunikaci s uživatelským prostorem a roura pravděpodobně jako berlička pro zpracování signálů na systémech, které nemají pselect(2).

Proč ale udev nechce ignorovat události ohledně uids, to nevím. Rozhodně bych doporučoval upgradovat, protože vztah mezi jádrem a udevd je velmi těsný.

[pht]

no, ty zmeny jsou v /sys a ne v /proc. ale na tom nezalezi. myslim si ze ty eventy nevznikaji pres inotify, ale pres nejaky jiny event interface (asi ten, ktery generuje procesy typu /sbin/udevsend uids). dival jsem se do linux/kernel/user.c a tam je celej proces videt ve funkci uids_user_create. me tvrzeni ze to ma neco spolecneho s group sched potvrzuje fakt, ze kdyz je group sched off, tak ta funkce uids_user_create je jen {return 0}.

je mozny ze je tohle nejaky starsi zpusob komunikace s udev a dnes uz se to dela jinak? udev je asi rok starej. jadro je aktualni. ale co mi vrta hlavou, proc udev startuje znova a znova kdyz se zabije? zeby ho poustel ten udevsend?

[petr_p]

Díval jsem se do 2.6.26-gentoo-r1 a pokud máte zakompilovanou podporu pro hotplug (CONFIG_HOTPLUG), tak se volá kobject_uevent_env() z lib/kobject.c, která pokud máte zahrnoutou podporu sítě (CONFIG_NET), tak pošle událost přes NETLINK socket, a pak ještě pokud je vyplněná konfigurační volba CONFIG_UEVENT_HELPER_PATH (standardně /sbin/hotplug), tak spustí uživatelský proces hotplug, který asi zavolá /sbin/udevsend (můj udev-124-r1 žádný takový soubor nemá).

Nicméně moderní udevd (resp. distribuce prosté hotplugu) likviduje tuto volbu vymazáním obsahu /proc/sys/kernel/hotplug, takže je jádrem otravován jen přes netlink socket.

Takže asi ano, záleží na verzi jádra a udevu, jak se systém bude chovat.

[pht]

diky, to bude ono.

# cat /proc/sys/kernel/hotplug 
/sbin/udevsend

ten udevsend pak asi kontroluje jestli udev nechcip a kdyztak ho pusti. to je ale prasarna.

[Michal Kubeček]

V podmínce byste měl mít operátor '==', ale myslím, že udev pořád podporuje i starou syntaxi s '='. Pokud to nepozná podle SUBSYSTEM, zkuste DEVPATH=="/kernel/uids/*" (a samozřejmě by to mělo být v souboru, který se bude zpracovávat jako první).

[pht]

ja jsem tam == chtel dat, ale jelikoz vsechny ostatni soubory pouzivaly =, tak jsem tam dal =. bude to asi starsi model udevu. az budu mit moznost to zas tejrat tak se na to podivam, bohuzel to asi nebude moc brzo protoze je to dost vytizenej stroj.