Mensagens de broadcast não aparecem no gnome-terminal, mas aparecem no xterm

4

Estou curioso sobre o comportamento de mensagens transmitidas por

$ sudo wall myfile

a mensagem de myfile aparece em todos os dispositivos /dev/ttyN (aqueles aos quais eu posso alternar pressionando Ctrl + Alt + fN ), ele também aparece na janela xterm que abri, mas não aparece em gnome-terminal (na verdade eu uso o Linux Mint com o MATE, então é mate-terminal , mas é bifurcação de gnome-terminal ).

Também há uma observação interessante se eu executar tmux no xterm : Espero que a mensagem apareça em todas as sessões de terminal em execução em tmux (em todas as janelas e em cada painel de cada janela) , mas na verdade a mensagem aparece apenas na posição atual do cursor na janela xterm .

Se eu verificar o terminal de controle atual chamando tty , ele reporta terminais diferentes para janelas diferentes no tmux: digamos, eu tenho /dev/pts/11 em uma janela tmux e /dev/pts/12 em outra. Mas, a mensagem de difusão aparece apenas uma vez para cada janela xterm , não para cada sessão de terminal aberta em tmux .

Parece-me que o emulador de terminal, ao alocar o pseudo-terminal, precisa "registrá-lo" em algum lugar para torná-lo capaz de receber mensagens de difusão e, portanto, xterm , mas mate-terminal e tmux não. Mas isso soa estranho, já que o pseudo-terminal é alocado pelo kernel, então, ele deve ser "registrado" automaticamente em todos os lugares que precisa ser.

Eu ficaria feliz se alguém explicar como funciona e por que o comportamento é assim (aparentemente esquisito).

    
por Dmitry Frank 17.08.2014 / 22:51

2 respostas

2

Os terminais listados indicam que o comportamento é visto no Linux: As dicas estão na página de manual para wall ( Solaris , por exemplo é diferente):

wall displays a message, or the contents of a file, or otherwise its standard input, on the terminals of all currently logged in users.

Some sessions, such as wdm, that have in the beginning of utmp(5) ut_type data a ':' character will not get the message from wall. This is done to avoid write errors.

Ou seja, wall usa os dados de utmp, procura terminais em uso (ou seja, usuários que efetuaram login) e grava no dispositivo associado. Cada linha na saída de w mostra um terminal (possível), gravado pelo terminal no arquivo utmp. Por exemplo, eu sou ssh'd em um servidor e tela de execução, enquanto ao mesmo tempo eu entrei em um console. Apenas por completo, executei o xterm usando a opção -ls (login-shell). Aqui está a saída de w :

$ w
 19:53:15 up  4:08,  5 users,  load average: 0.00, 0.01, 0.05
USER     TTY      FROM             LOGIN@   IDLE   JCPU   PCPU WHAT
tom      tty2                      19:48    5:11   0.04s  0.02s -tcsh
tom      pts/0    michener:S.0     15:51   13:18   0.35s  0.24s ssh -X thomas@b
tom      pts/2    michener:S.1     16:34    2.00s  0.14s  0.00s sh -c w
tom      pts/4    michener:S.3     15:52    3:59m  0.12s  0.00s /bin/sh /users/
tom      pts/3    localhost:10.0   19:53    7.00s  0.03s  0.03s -tcsh

e a execução de wall grava em cada um desses TTY dispositivos.

No entanto, se o terminal não gravar no arquivo utmp, ele não será listado - e wall irá ignorá-lo.

Agora, alguns programas podem ter o recurso compilado, mas falta privilégios para alterá-lo. É por isso que alguns programas são executados com setgid para o grupo "utmp". Outros programas (como o xterm - ou o gnome-terminal) podem usar um programa externo que atualiza o utmp em seu nome.

Com o gnome-terminal, o recurso foi preterido devido à mentalidade dos desenvolvedores do gnome que (a) os usuários executam em uma máquina local, onde gdm manipula o login e (b) conseqüentemente, não há distinção que valha a pena incomodar entre shells de login e shells de não-login. Isso cria alguns relatos de bugs interessantes:

por 17.05.2016 / 02:17
0

Em urxvt , você precisa emitir

chown root.utmp /usr/bin/urxvt
chmod g+s /usr/bin/urxvt

Em seguida, ele começa a funcionar.

Eu não entendo porque, apenas copiei (e testei) de link .

    
por 20.04.2016 / 17:43