ทำไมฉันไม่สามารถใช้ renice เพื่อเพิ่มมูลค่าที่ดีของกระบวนการได้?

จากman renice:

ผู้ใช้รายอื่นนอกเหนือจากผู้ใช้ขั้นสูงอาจเปลี่ยนลำดับความสำคัญของกระบวนการที่พวกเขาเป็นเจ้าของและสามารถเพิ่มค่าที่ดี 'ของพวกเขา (เพื่อเหตุผลด้านความปลอดภัย)ภายในช่วง 0 ถึง PRIO_MAX (20) [... ]

ดังนั้นฉันสามารถทำreniceกระบวนการของตัวเองให้สูงขึ้น (ให้ลำดับความสำคัญต่ำกว่า) แต่ไม่เคยลง:

$ 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

ทำไมนี้ ฉันสามารถเข้าใจได้ว่าทำไมผู้ใช้ปกติไม่สามารถตั้งค่าที่ดีได้ต่ำกว่า 0 แต่เพราะเหตุใดฉันสามารถลดลำดับความสำคัญเป็น 10 ฉันไม่สามารถเพิ่มความสำคัญเป็น 9 อีกครั้งได้ "เหตุผลด้านความปลอดภัย" มีไว้เพื่ออะไร ฉันมีสิทธิ์ที่จะเปิดตัวโปรเซสที่คุ้มค่าเป็น 9 ดังนั้นทำไมฉันไม่สามารถเปลี่ยนเป็น 9 ได้

แก้ไข: ฉันควรเรียนรู้ที่จะเลื่อนลง ปรากฎนี้ถูกระบุว่าเป็นข้อผิดพลาดใน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.

นั่นยิ่งทำให้สับสนมากขึ้น หากพวกเขาคิดว่าพฤติกรรมนี้เป็นข้อผิดพลาดทำไมไม่เปลี่ยนมัน? reniceคำสั่งที่ปรากฏใน 4.0BSD ซึ่งผมคิดว่าจากปี 1980 นี้ควรจะเป็นมากง่ายต่อการแก้ไขเพื่อให้บนมือข้างหนึ่งพวกเขาดูเหมือนจะได้เลือกที่จะปล่อยให้มันและที่อื่น ๆ พวกเขารายการว่ามันเป็นข้อผิดพลาด

ตั้งแต่ linux 2.6.12 นั่นขึ้นอยู่กับค่าของขีด จำกัด RLIMIT_NICE ( ulimit -e) ซึ่งสามารถรับค่าได้ตั้งแต่ 0 ถึง 40 ข้อ จำกัด นั้นเป็นข้อ จำกัด ในลำดับความสำคัญของกระบวนการมากขึ้น (ยิ่งจำนวนนั้นยิ่งมีความสำคัญสูงกว่าที่ผู้ใช้สามารถตั้งค่าสำหรับกระบวนการ)

คุณจะสังเกตเห็นค่าเริ่มต้นคือ 20 ใน ubuntu 10.04 และ 0 ใน Debian jessie เป็นต้น

ค่าnสำหรับขีด จำกัด นั้นหมายความว่ากระบวนการที่ไม่มีความสามารถ CAP_NICE สามารถเพิ่มระดับความสำคัญของกระบวนการให้สูงขึ้นได้nซึ่งหมายถึงการลดความสวยงามลงไปเป็นความ20 - nเหมาะสม ดังนั้นสำหรับค่า 0 หมายความว่าไม่มีผู้ใช้ที่ไม่มีสิทธิพิเศษสามารถลดความอ่อนโยนที่ต่ำกว่า 20 ได้ดังนั้นผู้ใช้ที่ไม่มีสิทธิพิเศษจะสามารถลดความสวยงามได้

ด้วยค่า 20 ผู้ใช้ที่ไม่มีสิทธิพิเศษสามารถลดความสวยงามกลับเป็น 0

ขึ้นอยู่กับผู้ดูแลระบบที่จะเลือกว่าจะอนุญาตให้ผู้ใช้ลดระดับความสำคัญของกระบวนการหรือไม่

ว่าทำไมผู้ดูแลระบบอาจจะไม่ต้องการให้ผู้ใช้ในการลดความสำคัญของกระบวนการของตนเองให้ดูคำตอบของ Flup

มันเป็นสิ่งที่ฉันต้องการโทรเหตุผลด้านนโยบาย แนวคิดคือผู้ใช้ปกติไม่สามารถแทนที่การกระทำของผู้ใช้ที่มีสิทธิ์

สมมติว่าคุณเป็นผู้ใช้บนเซิร์ฟเวอร์ที่ใช้ร่วมกันขนาดใหญ่ คุณกำลังใช้กระบวนการ CPU-hogging อันมหึมาต่อความเสียหายของผู้ใช้รายอื่น ดูแลระบบreniceของกระบวนการของคุณเพราะเขาไม่ชอบคุณมาก ระบบปฏิบัติการจำไม่ได้ว่าใครเป็นคนทำreniceแต่รู้ว่าผู้ใช้ปกติไม่สามารถย้อนกลับการดำเนินการ ด้วยวิธีนี้ดูแลระบบมีการควบคุมลำดับความสำคัญของกระบวนการของผู้ใช้ปกติ

แปลก ๆ มันใช้งานได้สำหรับฉัน

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

ตัวอย่าง

$ 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

การแก้ไขครั้งที่ 2

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

กำหนดค่าการเปลี่ยนแปลง

/etc/security/limits.conf

@audio          -       rtprio          100
@audio          -       nice            -10

และฉันเป็นสมาชิกของกลุ่มเสียงนี่คือการลดความหน่วงแฝงด้วยแจ็ค / ardor และบัฟเฟอร์ xruns เมื่อทำการบันทึก

renice

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