sysctl: unknown oid 'kern.maxdsiz'

Dan Lukes dan at obluda.cz
Thu Oct 29 19:29:09 CET 2009


Zdeněk Bill napsal/wrote, On 10/29/09 15:58:
> nedavno jsem narazil na problem, ze "najednou" mi zmizela pri upgradu 
> kernelu z 6.2R na 6.4STABLE v sysctl 'kern.maxdsiz'.

Vidis - a ja mel dojem, ze to nikdy sysctl nebylo.

> Pripadne na to prijit az na bezicim kernelu, kde jsem ani pri bootu 
> nezaznamenal, ze by neco zahlasilo, ze polozka kern.maxdsiz="1610612736" 
> v /boot/loader.conf byla ne/akceptovana.

To je nedorozumeni ...

> Druha vec, jak vlastne zjistit stav hodnoty, kdyz sysctl ji nezna?

... a tato otazka s tim bezprostredne souvisi.

Nic v /boot/loader.conf nenastavuje sysctl promenne. Na to je jiny 
konfigurak. V loader.conf se nastavuji promenne environmentu kernelu.

Zmateni patrne zpusobuje to, ze mnoho sysctl je deklarovano tak, aby 
jejich pocatecni hodnota byla prevzata ze ze stejnojmenne environmentove 
promenne pokud takova existuje.

Neni to ale povinnost - pocatecni hodnota sysctl muze byt na 
environmentu nezavisla.

A uz vubec to neznamena, ze kazda environmentova promenna musi mit svuj 
obraz ve stejnojmennem sysctl.

Pro environmentove hodnoty pritom neexistuje nejaka tabulka 
"pripustnosti", ktera by mohla byt za nasledek "neakceptovani". 
Environmentova promenna je proste objekt, ktery ma jmeno a hodnotu. 
Krome omezeni na mnozinu pripustnych znaku ve jmenu i hodnote zadne 
dalsi omezeni neni. Do loader.conf si mohu napsat prakticky jakekoliv 
prirazeni - a promenna s touto hodnotou se stane soucasti environmentu.

To ovsem neznamena, ze existuje nekdo, kdo bude kvuli tomu nejak menit 
svoje chovani. Promenne si proste nemusi nikdo vsimat. Tim se kernelovy 
environment nijak nelisi od environmentu aplikacniho.

Takze - podle me se ve skutecnosti nezmenilo nic. To, ze mas v 
loader.conf promennou, jejiz hodnotu nikdo nepouziva nezjistis (ale 
nemyslim, ze toto je ten pripad). A co se otazky "jak zjistit hodnotu 
kernel-environmentove promenne" (zmatecny dovetek "kdyz ji sysctl nezna" 
ignoruji):

man kenv

						Dan




More information about the Users-l mailing list