Mengapa saya tidak bisa menggunakan renice untuk meningkatkan nilai bagus suatu proses?

Dari man renice:

Pengguna selain pengguna super hanya dapat mengubah prioritas proses yang mereka miliki, dan hanya dapat secara monoton meningkatkan `` nilai bagus '' (untuk alasan keamanan) dalam kisaran 0 hingga PRIO_MAX (20) [...]

Jadi, saya bisa renicememproses sendiri ke atas (memberi mereka prioritas lebih rendah) tetapi tidak pernah ke bawah:

$ renice 10 22316
22316 (process ID) old priority 0, new priority 10
$ renice 9 22316
renice: failed to set priority for 22316 (process ID): Permission denied

Kenapa ini? Saya dapat memahami mengapa pengguna normal tidak dapat menetapkan nilai bagus lebih rendah dari 0, tetapi mengapa karena saya dapat mengurangi prioritas menjadi 10, saya tidak dapat meningkatkannya lagi menjadi 9? Apa "alasan keamanan" yang ada untuk ini? Saya memiliki hak untuk meluncurkan proses dengan nilai bagus 9, jadi mengapa saya tidak bisa mengubahnya menjadi 9?

EDIT: Saya harus belajar gulir ke bawah. Ternyata ini terdaftar sebagai bug di man renice:

BUGS
     Non super-users can not increase scheduling priorities of their own
     processes, even if they were the ones that decreased the priorities 
     in the first place.

Itu bahkan lebih membingungkan. Jika mereka menganggap perilaku ini sebagai bug, mengapa tidak mengubahnya? The reniceperintah muncul di 4.0BSD yang saya pikir adalah dari 1980. Ini harus sangat mudah untuk memperbaiki sehingga di satu sisi mereka tampaknya telah memilih untuk meninggalkannya dan di sisi lain mereka daftar sebagai bug.

nice priority

— terdon
sumber

Karena beberapa prioritas yang lebih tinggi dari 0 dapat ditegakkan oleh proses sistem atau modul keamanan dan tidak boleh dikurangi oleh pengguna (dan tidak ada kontrol yang cukup baik untuk mendefinisikan kebaikan minimal dari proses pengguna yang diberikan selain nilai tetap 0) ? Bukan jawaban karena saya tidak yakin tetapi hanya menebak.

— lgeorget

Pertanyaan yang sama di askubuntu .

— user202729

Jawaban:

Sejak linux 2.6.12, itu tergantung pada nilai batas RLIMIT_NICE ( ulimit -e). Yang dapat mengambil nilai dari 0 hingga 40. Batas itu lebih merupakan batas pada prioritas proses (semakin besar angka itu, semakin tinggi prioritas yang dapat ditetapkan pengguna untuk suatu proses).

Anda akan melihat nilai default adalah 20 di ubuntu 10,04 dan 0 di Debian jessie misalnya.

Nilai nuntuk batas itu berarti bahwa proses tanpa kapabilitas CAP_NICE hanya dapat meningkatkan prioritas proses hingga n, yang berarti mengurangi kebaikan hingga kebaikan 20 - n. Jadi untuk nilai 0, itu berarti tidak ada pengguna yang tidak memiliki hak istimewa yang dapat menurunkan kebaikan di bawah 20, jadi tidak ada pengguna yang tidak memiliki hak istimewa yang dapat menurunkan kebaikan.

Dengan nilai 20, pengguna yang tidak memiliki hak istimewa dapat menurunkan kembali ke 0.

Terserah administrator untuk memilih apakah mereka mengizinkan pengguna untuk menurunkan prioritas proses mereka, dan ke level apa dengan menetapkan batas keras untuk itu.

Mengenai mengapa administrator mungkin tidak ingin pengguna menurunkan prioritas proses mereka, lihat jawaban Flup .

— Stéphane Chazelas
sumber

Ah! Jadi bisa dikonfigurasi! Oke, itu lebih masuk akal, terima kasih.

— terdon

"nilai dari 0 hingga 40. [...] Anda akan melihat nilai defaultnya adalah 20 di ubuntu 10.04 dan 0 di Debian jessie misalnya." -> Menarik, sulit / lunak bagi saya memang 0 di debian jessie. Saya dapat menaikkan hingga 20 tetapi di luar itu saya mendapatkan "bash: ulimit: prioritas penjadwalan: tidak dapat mengubah batas: Argumen tidak valid", nilai negatif juga tidak diterima.

— thomanski

Ini untuk apa yang saya sebut alasan kebijakan . Idenya adalah bahwa pengguna normal tidak dapat mengesampingkan tindakan pengguna istimewa.

Katakanlah Anda adalah pengguna di beberapa server bersama yang sangat besar. Anda menjalankan proses hogging CPU yang sangat besar sehingga merugikan pengguna lain. Sysadmin reniceadalah beberapa proses Anda karena dia tidak begitu menyukaimu. OS tidak ingat siapa yang melakukan itu renice, tetapi ia tahu bahwa pengguna normal tidak dapat membalikkan tindakan. Dengan cara ini, sysadmin memiliki kendali atas prioritas proses pengguna normal.

— Flup
sumber

Saya bisa mengerti itu tetapi masih terasa aneh. Bahkan, saya baru menyadari bahwa itu bahkan terdaftar sebagai bug di man renice.

— terdon

Saya pikir inti dari bug adalah bahwa 'Non-pengguna super tidak dapat meningkatkan prioritas penjadwalan dari proses mereka sendiri, bahkan jika mereka adalah orang-orang yang menurunkan prioritas di tempat pertama '. yaitu efek samping dari penegakan ini bahwa kecelakaan renicetidak dapat dibalik kecuali oleh pengguna yang memiliki hak istimewa.

— Flup

Karena sistem tidak ingat siapa yang menetapkan prioritas. Idealnya, jika Anda menaikkan level yang bagus dan kemudian ingin menurunkannya, itu akan diizinkan ... tetapi sistem memberlakukan larangan selimut justru karena tidak menyimpan catatan tentang siapa yang membuat apa, sehingga Anda tidak dapat membatalkan reniceitu rootberhasil.

— Flup

@IwillnotexistIdonotexist memikirkan sistem dengan banyak pengguna. Sysadmin mungkin ingin meningkatkan prioritas proses Anda menjadi 5 dan menurunkan proses saya menjadi 10. Itu masih dalam kisaran pengguna normal, tetapi saya tidak akan dapat mengubahnya dan mencuri waktu CPU yang layak Anda dapatkan. Itulah idenya seperti yang dijelaskan Flup. Namun, seperti dijelaskan StephaneChazelas , ini dapat dikonfigurasi sehingga terserah sysadmin untuk memilih apa yang mereka sukai.

— terdon

Jawaban untuk "mengapa?" Kemungkinan besar adalah "karena tidak ada yang cukup membutuhkannya untuk menulis kode untuk memperbaikinya." Ketika Unix awalnya ditulis, pelacakan yang menetapkan prioritas suatu proses mungkin mahal dalam hal penggunaan memori dan bekerja untuk memperbaruinya, tetapi pada mesin modern, itu dapat diabaikan, hanya menyisakan kurangnya motivasi untuk menulis kode untuk melacak ini untuk situs yang ingin mempertahankan kebijakan asli "pengguna tidak dapat mengesampingkan sysadmin."

— alanc

-1

Aneh? ini bekerja untuk saya

Linux clafujiu 2.6.32-57-generic #119-Ubuntu \
 SMP Wed Feb 19 01:04:55 UTC 2014 i686 GNU/Linux

contoh

$ renice 8 --pid 21122
21122: old priority 9, new priority 8
christian@clafujiu:~/tmp$ ps eo "%p %n"
  PID  NI
 4190   0
 8594   0
14684   0
21122   8
21146   0
21155   0
21209   0
christian@clafujiu:~/tmp$ renice 15 --pid 21122
21122: old priority 8, new priority 15
christian@clafujiu:~/tmp$ ps eo "%p %n"
  PID  NI
 4190   0
 8594   0
14684   0
21122  15
21146   0
21155   0
21211   0
christian@clafujiu:~/tmp$ renice 10 --pid 21122
21122: old priority 15, new priority 10
christian@clafujiu:~/tmp$ ps eo "%p %n"
  PID  NI
 4190   0
 8594   0
14684   0
21122  10
21146   0
21155   0
21213   0

Sunting 2

$ cat /etc/lsb-release 
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=10.04
DISTRIB_CODENAME=lucid
DISTRIB_DESCRIPTION="Ubuntu 10.04.4 LTS"

Konfigurasi perubahan

/etc/security/limits.conf

@audio          -       rtprio          100
@audio          -       nice            -10

Dan saya anggota grup audio, ini untuk mengurangi latensi dengan jack / ardor dan buffer xruns saat merekam.

renice

$ renice --version
renice from util-linux-ng 2.17.2

— X Tian
sumber

Di distro apa Anda? itu tidak pada AIX 6.2

— Kiwy

Silakan posting output cat /etc/lsb*dan renice --versionjuga.

— terdon

renice --version renice from util-linux-ng 2.17.2tapi masih di AIX itu tidak mungkin

— Kiwy