Como ver qual arquivo um usuário está editando no vi

Question

Se eu fizer um w , posso ver que um usuário está editando um determinado arquivo no vi.

No entanto, existem vários arquivos com o mesmo nome em diretórios diferentes.

Como eu vejo qual desses arquivos é o que o usuário está editando?

    

Answer 1

Você pode usar lsof selecionando o usuário e pesquisando o processo vim como em:

sudo lsof -u user -a -c vim | grep swp

Como @fox aponta, o clássico vi cria um arquivo temporário em /var/tmp , então a alternativa para vê-lo deve ser (não testada).

sudo lsof -u user -a -c vi | grep '/var/tmp/'

No entanto, como aponta @Fox, você não será capaz de correlacioná-lo com o vi clássico para o arquivo real, e então você precisaria das ferramentas que eu falo a seguir na resposta (para o clássico vi , para vim bastaria o lsof ); geralmente atualmente no Linux você está usando vim ao invocar vi .

Veja 15 Exemplos de comandos Linux lsof (Identify Open Files)

Voltando ao exemplo vim , veremos então o arquivo de swap sendo usado com o nome de file é aberto como em .file.swp

Se o usuário user1 estiver fazendo vi file :

$ sudo lsof -c vi -a -u user1 | grep swp
vi      3615  user1  3u   REG    8,1    12288 265061 /home/user1/.file.swp

De man lsof

-a causes list selection options to be ANDed

-cc This option selects the listing of files for processes executing the command that begins with the characters of c. Multiple commands may be specified, using multiple -c options. They are joined in a single ORed set before participating in AND option selection.

-u s This option selects the listing of files for the user whose login names or user ID numbers are in the comma-separated set s

Além de lsof , você também pode usar como root, sysdig , que é um poderoso framework de depuração:

Isso mostrará todos os arquivos abertos no sistema em tempo real, listando usuário, pid e processo assim que forem abertos:

sudo sysdig -p "%12user.name %6proc.pid %12proc.name %3fd.num %fd.typechar %fd.name" evt.type=open"

sysdig: system-level exploration and troubleshooting tool

Sysdig instruments your physical and virtual machines at the OS level by installing into the Linux kernel and capturing system calls and other OS events. Then, using sysdig's command line interface, you can filter and decode these events in order to extract useful information and statistics.

Sysdig can be used to inspect live systems in real-time, or to generate trace files that can be analyzed at a later stage.

Como outra ferramenta útil para administradores de sistema, você também pode instalar o snoopy , que registra todas as invocações de processos chamados para o syslog. Se o usuário invocar na linha de comando vi file , você o verá nos registros do sistema.

Tenha em atenção que depois de snoopy ser instalado, ele irá registar todas as invocações do processo através de execve () até que o desinstale (o que pode querer ou não querer que esteja a acontecer o tempo todo).

snoopy: execve() wrapper and logger

snoopy is merely a shared library that is used as a wrapper to the execve() function provided by libc as to log every call to syslog (authpriv). system administrators may find snoopy useful in tasks such as light/heavy system monitoring, tracking other administrator's actions as well as getting a good 'feel' of what's going on in the system (for example Apache running cgi scripts).

Para instalar snoopy e sysdig :

$sudo apt-get install snoopy sysdig

Veja também a questão relacionada: Entendendo o que é um binário do Linux está fazendo

    

Answer 2

Isso pode funcionar em alguns casos. Você pode usar ps para encontrar o ID do processo da instância vi editando o arquivo:

$ w
...
username  pts/2    :0.0             11:42    2:34m  0.28s  0.27s vim foo

$ ps aux | grep 'vim foo'
...
username  55899 .... vim foo

Em seguida, como root, veja os descritores de arquivos abertos associados a esse pid:

# ls -l /proc/55899/fd
...
lrwx------ 1 username group 64 Feb  8 14:23 6 -> /path/to/.foo.swp

Dado que, então você pode concluir que o arquivo é /path/to/foo .

    

Answer 3

Você precisa usar lsof :

$ lsof  |grep -i vim

    

Answer 4

você quer ver isso de dentro do vi ou do shell? -de vim

<ESC>:ls list buffers opened 

Acho que o vi não pode, mas você pode usar ctrl+ww para alternar entre arquivos

-de shell

lsof | grep -i  vi 

    

Answer 5

Suponho que você saiba qual comando o usuário executou, mas deseja saber de qual diretório ele foi executado (para que, se eles executassem vi myfile.txt , você soubesse se é /home/user/myfile.txt ou /tmp/myfile.txt ou algo mais).

Nesse caso, supondo que você esteja executando como root, você pode fazer:

readlink /proc/<pid>/cwd

em que <pid> é o ID do processo vi / vim em que você está interessado - que informará o diretório atual desse processo, que tem uma boa chance de ser o desejado.

Note, no entanto, que:

• O usuário pode alterar o diretório atual do processo depois de iniciar o editor (por exemplo, usando o comando :cd ). Você também pode querer verificar o diretório atual do processo do shell que gerou o editor, embora não seja 100% confiável.
• O usuário pode abrir outros arquivos, e isso não aparecerá na linha de comando - então eles podem estar editando algo totalmente diferente.

Answer 6

Se você não tem root, mas tem permissões para ler os diretórios, sua melhor aposta é provavelmente procurar os arquivos .swp para o arquivo em questão (assumindo que o usuário não alterou o local de troca padrão do vim! ):

$ find . -type f
./1/foo
./0/foo
./2/foo

$ cd 1
$ vi foo
^Z 
[1] 19650

$ cd ..
$ find -type f
./1/foo
./1/.foo.swp
./0/foo
./2/foo

Observe, no entanto, se você editar foo e .foo no mesmo diretório, vim precisará fazer extensões de nome de arquivo temporário diferentes:

-rw-r--r--   1 user grp  12288 Feb  8 14:59 .foo.swo
-rw-------   1 user grp   4096 Feb  8 14:58 .foo.swp

Então, você pode querer procurar usando find . -user username -name '.*.sw*'

Isso parece um problema XY - que problema maior você está tentando resolver? Se você está tentando gerenciar vários usuários que estão editando arquivos comuns, talvez queira mover para um sistema de gerenciamento de origem.