Como matar todo o processo de um outro espaço de trabalho quando o sistema é enforcado e incapaz de se mover de um WS para outro. deixe-me desenhar o cenário.
WS: espaço de trabalho
no WS1: tocando uma música via site on-line através da ópera.
trabalhando no WS3 e recebendo skype, ligue para
agora tentei seguir em frente no ws1 (Ctrl + Alt + Shift + & lt; =) mas não está funcionando
está tudo bem no WS3 (mesmo escrevendo este problema)
Agora, quero liberar o fone de ouvido do site da música.
o que fazer para liberar o fone de ouvido (controlador de áudio) para que ele pare.
Abra o mesmo site no mesmo navegador que o espaço de trabalho para que ele pare (falhe)
tentando xkill mas não funciona
conecte e desconecte o fone de ouvido USB, mas isso não funciona
por favor, sugira qualquer forma de realizar sem ser desligado
Que tal alt + F2 & amp; digite killall opera - isso fechará o Opera, e provavelmente todos os subprocessos.
Quando você reiniciar, se ele se comportar como o Firefox, ele será retomado com todas as guias mantidas. (Eu não uso o Opera - então, neste ponto, não tenho certeza).
Se ele se recusar a morrer, use sudo killall -9 opera , que é mais pesado, mas deve fazê-lo.
Se você conhece o processo que o Opera está usando para jogar, você pode simplesmente matar isso - mais sutil!
Os espaços de trabalho são uma abstração da maioria dos gerenciadores de janelas (GNOME, KDE, LXDE, OpenBox, BusyBox, etc.). No entanto, honestamente, eles estão lá apenas para fins organizacionais e não refletem o comportamento subjacente dos processos reais. Com isso, quero dizer que cada processo não está vinculado a um processo de espaço de trabalho.
Digamos que você abra o Opera no espaço de trabalho no GNOME. Uma árvore de processos parciais pode ser algo assim:
GNOME
Firefox
Agora, digamos que você mude para o espaço de trabalho dois e inicie o Rhythmbox:
GNOME
Firefox
Rhythmbox
Assim, como você pode ver, do ponto de vista de uma hierarquia de processo subjacente, não há como separar quais aplicativos estão sendo executados em qual espaço de trabalho. Neste ponto, somente o gerenciador de janelas sabe quais aplicativos (na verdade, janelas de aplicativos) aparecem em qual espaço de trabalho. Portanto, a menos que haja uma maneira de consultar o gerenciador de janelas (neste caso, o GNOME) sobre quais janelas estão em um espaço de trabalho e para o qual essas janelas pertencem, não haveria uma maneira fácil de fazer isso. isso.
Há também o cenário em que você pode ter um processo com duas janelas. Por exemplo, você pode ter duas janelas do Opera com uma janela em cada espaço de trabalho. Fazer isso teria o efeito colateral de fechar todas as janelas do Opera, mesmo na área de trabalho não problemática, já que é mais do que provável (não tenho certeza sobre o Opera, mas sei que o Firefox se comporta dessa maneira) o mesmo processo. Então, mesmo que fosse viável, pode muito bem haver algumas conseqüências não intencionais disso.
Então, resumindo: não, não há como matar processos dependendo de qual espaço de trabalho eles residem. Nesse caso, eu faria @diEcho descrito e mudaria para um terminal virtual ( Ctrl - Alt - F1 através de F6 geralmente) e mata o processo problemático com o comando kill . Claro, isso pressupõe que você saiba qual processo está causando o problema, o que nem sempre é o caso.
Para seu problema específico relacionado ao áudio, há outra maneira de realizar essa tarefa: pavucontrol (supondo que você esteja usando o padrão PulseAudio e não Jack, ALSA ou OSS). O Pavucontrol permite ajustar o volume de aplicações individuais ou emudecer. Então, enquanto isso não consertaria a incapacidade de ir para o WS1 e derrubar diretamente o Opera, ele teria resolvido o problema de áudio.