Imposta il valore predefinito di default per un determinato utente (limits.conf)

Qualcuno potrebbe dirmi come impostare il valore predefinito di nice(come visualizzato da top) di un utente? Ho scoperto che /etc/security/limits.conf è il posto giusto, ma se metto uno dei due:

username_of_a_guy  -  nice  19
username_of_a_guy  soft  nice  19
username_of_a_guy  hard  nice  19

Non funziona (mentre dovrebbe, giusto?).

Nota che da allora ho riavviato.

Grazie mille in anticipo per qualsiasi aiuto. Sto usando debian unstable (aggiornato).

Contesto:

Nel mio lavoro, abbiamo una rete locale: ognuno ha il proprio computer e tutti possono creare un account sulla macchina di qualcun altro, se uno piace. La regola empirica è semplicemente che se lavori su qualcun altro computer, ti preghiamo di perfezionare i tuoi processi ( nice 19).

Vorrei impostare il valore predefinito di default per un determinato utente su 19 una volta per tutte.

— alex
fonte

In qualche modo correlato: unix.stackexchange.com/questions/209398/…

— Kusalananda

Risposte:

Credo che il formato corretto sia:

@users      -       priority        10
username    -       priority        19

Questo è un esempio delle impostazioni che sto usando in produzione (ovviamente con utenti / gruppi reali).

L' niceimpostazione è determinare il valore minimo piacevole (ovvero la priorità massima) a cui qualcuno può impostare il processo, non la priorità predefinita.

— jsbillings
fonte

Innanzitutto, grazie per la risposta (grazie anche a @mattdm). Sembra che questo metodo funzioni. Tuttavia, sono ancora confuso sulla differenza tra "bello" e "priorità": entrambi sono visualizzati da "alto" ma il valore indicato per bello è quello che devo impostare per priorità. Mi sembra un po 'strano. Inoltre, una priorità più grande (diciamo 39 invece di 20) significa un processo meno importante come per il bello? Grazie.

— Alex

La bella priorità "NI" in alto è quella che verrebbe impostata dall'impostazione dei limiti priority. Questa sarà la priorità predefinita di tutti i processi per quell'utente / gruppo quando effettuano l'accesso. Puoi solo impostarlo tra -20 e 20. Il valore 'PR' in alto è la priorità effettiva dello scheduler, che è determinata da diversi fattori dello scheduler del kernel.

— jsbillings

Inoltre, sì, una priorità più alta significa che è meno probabile che sia pianificato per ottenere cicli di CPU.

— jsbillings

Ok, grazie mille per questa chiarimento. A proposito, non ho provato altri metodi (che coinvolgono ando cgroup) che potrebbero essere migliori in altre situazioni diverse dalla mia (necessità di un controllo continuo o gestione di molti utenti, che è un po 'troppo nel mio caso).

— Alex

Hmmmm ... Questo ha funzionato per un utente ma non per l'altro sulla mia macchina Ubuntu. Tornerò se riesco a capire perché. ;-)

— Ken Sharp

Posso confermare che non funziona neanche sul mio sistema. I documenti dicono "kernel 2.6.11 e successivi", e sono su Fedora rawhide con kernel 2.6.38-rc6. Mi chiedo se è dipendente dallo scheduler e non funziona con il CFQ introdotto-in-2.6.23 ("Completely Fair Scheduler").

Qualcosa che funzionerà, però, è l'impossibile da cercare per il suo nome orribile and: il demone auto-simpatico. Vedi http://and.sourceforge.net/ . Questo è disponibile da Fedora con yum install and, ma sfortunatamente non sembra essere in EPEL. Ed è in Debian troppo: apt-get install and.

Se stai usando una distribuzione moderna, però, c'è un modo ancora migliore. È possibile utilizzare gli strumenti di libcgroup per impostare un cgroup a livello di kernel che limiti le condivisioni della CPU e per "classificare" automaticamente i processi dell'utente in questo cgroup. Con questo, è anche possibile dare priorità all'I / O e limitare l'utilizzo della memoria (inclusa la condivisione della cache del disco).

— mattdm
fonte

Sono d'accordo che l'uso di cgroups è un modo eccellente per limitare altre persone dal fare il hogging su tutti i cicli della CPU sul tuo computer. Purtroppo, i sistemi che supporto (RHEL5) non hanno kernel che lo supportano, quindi devo attenermi alla regolazione della priorità. Dopo l'aggiornamento a RHEL6, sono sicuro che avremo alcune impostazioni cgroups abbastanza complesse.

— jsbillings