chrt (): “falha ao definir a política do pid XXX” em uma máquina, mas não em outras

Question

Eu tenho várias máquinas Linux, todas executando o mesmo kernel (Ubuntu 12.04, 3.5.0-45-generic ). Em um deles, não consigo usar chrt . Se eu tentar usá-lo em um novo processo, recebo o seguinte erro:

$ sudo chrt -f 1 ls
chrt: failed to set pid 0's policy: Operation not permitted

Se eu tentar usá-lo em um processo existente, recebo um erro semelhante:

$ stress -c 1 &
[1] 3929
$ sudo chrt -f -p 1 3929
chrt: failed to set pid 3929's policy: Operation not permitted

Estou operando como superusuário, portanto, devo ter CAP_SYS_NICE e, de fato, posso nice ou renice um processo; Eu simplesmente não consigo ajustar suas propriedades em tempo real.

Esse comportamento é exclusivo para essa única máquina; o comportamento persiste durante a reinicialização e o lançamento de um novo shell em um ambiente separado ( env -i bash --noprofile --norc ).

Se eu tentar executar este comando em qualquer uma das outras máquinas (toda a mesma distribuição, mas algumas com hardware diferente), ela será bem-sucedida como esperado.

A explicação mais próxima que encontrei foi postagem dos grupos do Google na qual alguém afirmou que o mesmo problema foi devido ao uso do cpuset. Não consegui encontrar nenhuma elaboração. Eu já fiz algum trabalho nesta máquina com afinidades de thread ( pthread_setaffinity_np() ), taskset, cpusets, isolcpus, etc. No entanto, eu não sei como qualquer um deles ainda pode estar causando esse comportamento, já que eu não estou explicitamente definir quaisquer prioridades e, por taskset -p $$ mostra o conjunto completo de CPUs (conforme esperado). Além disso, verifiquei duas vezes que ainda não estou executando com CPUs isoladas ( cat /proc/cmdline ).

Existe alguma configuração que eu esteja negligenciando? Qualquer sugestão seria muito apreciada

EDITAR Conforme a sugestão de @ bersch, estou incluindo trechos da execução de strace . Em um ajuste de máquina de trabalho para prioridade 13:

sched_setscheduler(2475, SCHED_FIFO, { 13 }) = 0 # PID 2475
sched_setscheduler(0, SCHED_FIFO, { 13 }) = 0 # ls 

O mesmo na máquina quebrada:

sched_setscheduler(6248, SCHED_FIFO, { 13 }) = -1 EPERM (Operation not permitted) # PID 6248
sched_setscheduler(0, SCHED_FIFO, { 13 }) = -1 EPERM (Operation not permitted) # ls

Isso é exatamente o que eu esperaria das mensagens de erro.

    

Answer 1

A postagem nos Grupos do Google e a sugestão do @ bersch de procurar pela chamada sched_setscheduler diretamente (em vez do invólucro da linha de comando chrt ) me ajudaram a responder: de fato, foi por causa do uso do cpuset. Eu tinha esquecido que cgroups é usado para suportar cpusets .

Uma pesquisa por sched_getscheduler e cgroup aumentou uma tonelada de hits, incluindo

link

De qualquer forma, atualmente não tenho necessidade de cgroups, então desativei:

sudo service cgconfig stop

Agora tudo funciona como esperado.

Editar Para que a alteração persistisse após a reinicialização, tive que comentar o conteúdo de /etc/cgconfig.conf também.

    

Answer 2

Eu tive o mesmo problema. O seguinte comando corrigiu:

sysctl -w kernel.sched_rt_runtime_us=-1

Fonte: link