Как контролировать, какие файлы открыты

Question 1

Есть ли инструмент для мониторинга того, какие процессы открывают какие файлы в системе, чтобы вы могли отслеживать, какой процесс продолжает касаться определенного файла?

Lsof может узнать, запускаете ли вы его, пока процесс имеет файл открыт, но если это непродолжительный процесс, который выполняется каждый раз в то время, вы не можете его поймать lsof. Нужно что-то, что использует трассировку ядра.

Question 2

Вы могли бы использовать систему аудита для этого. Это немного тяжеловес, но что-то вроде этого должно работать (в /etc/audit/audit.rules):

# delete all other rules
-D

# watch the file in question
-w /path/to/file -p rwxa

, а затем, я думаю, вам нужно перезапустить auditd:

sudo service audit restart

(Если у вас его нет, он находится в пакете auditd.) В этом случае виновник может быть найден в /var/log/audit/audit.log.

Question 3

Question 4

Вы могли бы использовать систему аудита для этого. Это немного тяжеловес, но что-то вроде этого должно работать (в /etc/audit/audit.rules):

# delete all other rules
-D

# watch the file in question
-w /path/to/file -p rwxa

, а затем, я думаю, вам нужно перезапустить auditd:

sudo service audit restart

(Если у вас его нет, он находится в пакете auditd.) В этом случае виновник может быть найден в /var/log/audit/audit.log.

Question 5

Вы могли бы использовать систему аудита для этого. Это немного тяжеловес, но что-то вроде этого должно работать (в /etc/audit/audit.rules):

# delete all other rules
-D

# watch the file in question
-w /path/to/file -p rwxa

, а затем, я думаю, вам нужно перезапустить auditd:

sudo service audit restart

(Если у вас его нет, он находится в пакете auditd.) В этом случае виновник может быть найден в /var/log/audit/audit.log.

Question 6

Вы могли бы использовать систему аудита для этого. Это немного тяжеловес, но что-то вроде этого должно работать (в /etc/audit/audit.rules):

# delete all other rules
-D

# watch the file in question
-w /path/to/file -p rwxa

, а затем, я думаю, вам нужно перезапустить auditd:

sudo service audit restart

(Если у вас его нет, он находится в пакете auditd.) В этом случае виновник может быть найден в /var/log/audit/audit.log.

Question 7

Question 8

Вы могли бы использовать систему аудита для этого. Это немного тяжеловес, но что-то вроде этого должно работать (в /etc/audit/audit.rules):

# delete all other rules
-D

# watch the file in question
-w /path/to/file -p rwxa

, а затем, я думаю, вам нужно перезапустить auditd:

sudo service audit restart

(Если у вас его нет, он находится в пакете auditd.) В этом случае виновник может быть найден в /var/log/audit/audit.log.

Question 9

Вы могли бы использовать систему аудита для этого. Это немного тяжеловес, но что-то вроде этого должно работать (в /etc/audit/audit.rules):

  # удалять все остальные правила -D # смотреть этот файл -w /  path / to / file -p rwxa

, а затем, я думаю, вам нужно перезапустить auditd:

  sudo service audit restart

(Если у вас его нет, он находится в пакете auditd.) В этом случае виновник можно найти в /var/log/audit/audit.log.

Question 10

Вы могли бы использовать систему аудита для этого. Это немного тяжеловес, но что-то вроде этого должно работать (в /etc/audit/audit.rules):

  # удалять все остальные правила -D # смотреть этот файл -w /  path / to / file -p rwxa

, а затем, я думаю, вам нужно перезапустить auditd:

  sudo service audit restart

(Если у вас его нет, он находится в пакете auditd.) В этом случае виновник можно найти в /var/log/audit/audit.log.

Question 11

Вы могли бы использовать систему аудита для этого. Это немного тяжеловес, но что-то вроде этого должно работать (в /etc/audit/audit.rules):

  # удалять все остальные правила -D # смотреть этот файл -w /  path / to / file -p rwxa

, а затем, я думаю, вам нужно перезапустить auditd:

  sudo service audit restart

(Если у вас его нет, он находится в пакете auditd.) В этом случае виновник можно найти в /var/log/audit/audit.log.

Question 12

Вы могли бы использовать систему аудита для этого. Это немного тяжеловес, но что-то вроде этого должно работать (в /etc/audit/audit.rules):

  # удалять все остальные правила -D # смотреть этот файл -w /  path / to / file -p rwxa

, а затем, я думаю, вам нужно перезапустить auditd:

  sudo service audit restart

(Если у вас его нет, он находится в пакете auditd.) В этом случае виновник можно найти в /var/log/audit/audit.log.

Question 13

Question 14

К сожалению, механизм, который использует Linux для мониторинга файлов, isotify, который не предоставляет достаточной информации для извлечения полезных данных: вы получаете только имя файла и действие, которое было выполнено.

ve попытался использовать что-то вроде этого:

sudo inotifywait -mr somedir --format "%w%f" | while read file; do echo -n "$file => ";lsof -b $file; echo ""; done

Слушает, чтобы инициализировать события в указанном каталоге и для каждого запускаемого события lsof, чтобы попытаться поймать процесс, затрагивающий файл. К сожалению, для большинства запросов, которые я тестировал (например, используя редактор для записи в файл), команда LSOF просто замедляется и не удается поймать процесс нарушения.

Если ваши процессы делают еще несколько интенсивный ввод-вывод в проблемных файлах, то ваш пробег может отличаться. Удачи.

Question 15

К сожалению, механизм, который использует Linux для мониторинга файлов, isotify, который не предоставляет достаточной информации для извлечения полезных данных: вы получаете только имя файла и действие, которое было выполнено.

ve попытался использовать что-то вроде этого:

sudo inotifywait -mr somedir --format "%w%f" | while read file; do echo -n "$file => ";lsof -b $file; echo ""; done

Слушает, чтобы инициализировать события в указанном каталоге и для каждого запускаемого события lsof, чтобы попытаться поймать процесс, затрагивающий файл. К сожалению, для большинства запросов, которые я тестировал (например, используя редактор для записи в файл), команда LSOF просто замедляется и не удается поймать процесс нарушения.

Если ваши процессы делают еще несколько интенсивный ввод-вывод в проблемных файлах, то ваш пробег может отличаться. Удачи.

Question 16

К сожалению, механизм, который использует Linux для мониторинга файлов, isotify, который не предоставляет достаточной информации для извлечения полезных данных: вы получаете только имя файла и действие, которое было выполнено.

ve попытался использовать что-то вроде этого:

sudo inotifywait -mr somedir --format "%w%f" | while read file; do echo -n "$file => ";lsof -b $file; echo ""; done

Слушает, чтобы инициализировать события в указанном каталоге и для каждого запускаемого события lsof, чтобы попытаться поймать процесс, затрагивающий файл. К сожалению, для большинства запросов, которые я тестировал (например, используя редактор для записи в файл), команда LSOF просто замедляется и не удается поймать процесс нарушения.

Если ваши процессы делают еще несколько интенсивный ввод-вывод в проблемных файлах, то ваш пробег может отличаться. Удачи.

Question 17

К сожалению, механизм, который использует Linux для мониторинга файлов, isotify, который не предоставляет достаточной информации для извлечения полезных данных: вы получаете только имя файла и действие, которое было выполнено.

ve попытался использовать что-то вроде этого:

sudo inotifywait -mr somedir --format "%w%f" | while read file; do echo -n "$file => ";lsof -b $file; echo ""; done

Слушает, чтобы инициализировать события в указанном каталоге и для каждого запускаемого события lsof, чтобы попытаться поймать процесс, затрагивающий файл. К сожалению, для большинства запросов, которые я тестировал (например, используя редактор для записи в файл), команда LSOF просто замедляется и не удается поймать процесс нарушения.

Если ваши процессы делают еще несколько интенсивный ввод-вывод в проблемных файлах, то ваш пробег может отличаться. Удачи.

Question 18

К сожалению, механизм, который использует Linux для мониторинга файлов, isotify, который не предоставляет достаточной информации для извлечения полезных данных: вы получаете только имя файла и действие, которое было выполнено.

ve попытался использовать что-то вроде этого:

sudo inotifywait -mr somedir --format "%w%f" | while read file; do echo -n "$file => ";lsof -b $file; echo ""; done

Слушает, чтобы инициализировать события в указанном каталоге и для каждого запускаемого события lsof, чтобы попытаться поймать процесс, затрагивающий файл. К сожалению, для большинства запросов, которые я тестировал (например, используя редактор для записи в файл), команда LSOF просто замедляется и не удается поймать процесс нарушения.

Если ваши процессы делают еще несколько интенсивный ввод-вывод в проблемных файлах, то ваш пробег может отличаться. Удачи.

Question 19

Question 20

К сожалению, механизм, который Linux использует для мониторинга файлов, isotify, который не предоставляет достаточной информации для извлечения полезных данных: вы получаете только имя файла и действие, которое было выполнено.

вы пытались использовать что-то вроде этого:

  sudo inotifywait -mr somedir --format "% w% f" |  при чтении файла;  do echo -n "$ file = & gt;"; lsof -b $ file;  эхо "";  done

Слушает для инициализации событий в указанном каталоге и для каждого выполняемого события lsof, чтобы попытаться поймать процесс, затрагивающий файл. К сожалению, для большинства запросов, которые я тестировал (например, с помощью редактора для записи в файл), команда LSOF просто замедляется и не удается поймать процесс нарушения.

Если ваши процессы делают еще несколько интенсивный ввод-вывод в проблемных файлах, то ваш пробег может отличаться. Удачи.

Question 21

К сожалению, механизм, который Linux использует для мониторинга файлов, isotify, который не предоставляет достаточной информации для извлечения полезных данных: вы получаете только имя файла и действие, которое было выполнено.

вы пытались использовать что-то вроде этого:

  sudo inotifywait -mr somedir --format "% w% f" |  при чтении файла;  do echo -n "$ file = & gt;"; lsof -b $ file;  эхо "";  done

Слушает для инициализации событий в указанном каталоге и для каждого выполняемого события lsof, чтобы попытаться поймать процесс, затрагивающий файл. К сожалению, для большинства запросов, которые я тестировал (например, с помощью редактора для записи в файл), команда LSOF просто замедляется и не удается поймать процесс нарушения.

Если ваши процессы делают еще несколько интенсивный ввод-вывод в проблемных файлах, то ваш пробег может отличаться. Удачи.

Question 22

К сожалению, механизм, который Linux использует для мониторинга файлов, isotify, который не предоставляет достаточной информации для извлечения полезных данных: вы получаете только имя файла и действие, которое было выполнено.

вы пытались использовать что-то вроде этого:

  sudo inotifywait -mr somedir --format "% w% f" |  при чтении файла;  do echo -n "$ file = & gt;"; lsof -b $ file;  эхо "";  done

Слушает для инициализации событий в указанном каталоге и для каждого выполняемого события lsof, чтобы попытаться поймать процесс, затрагивающий файл. К сожалению, для большинства запросов, которые я тестировал (например, с помощью редактора для записи в файл), команда LSOF просто замедляется и не удается поймать процесс нарушения.

Если ваши процессы делают еще несколько интенсивный ввод-вывод в проблемных файлах, то ваш пробег может отличаться. Удачи.

Question 23

К сожалению, механизм, который Linux использует для мониторинга файлов, isotify, который не предоставляет достаточной информации для извлечения полезных данных: вы получаете только имя файла и действие, которое было выполнено.

вы пытались использовать что-то вроде этого:

  sudo inotifywait -mr somedir --format "% w% f" |  при чтении файла;  do echo -n "$ file = & gt;"; lsof -b $ file;  эхо "";  done

Слушает для инициализации событий в указанном каталоге и для каждого выполняемого события lsof, чтобы попытаться поймать процесс, затрагивающий файл. К сожалению, для большинства запросов, которые я тестировал (например, с помощью редактора для записи в файл), команда LSOF просто замедляется и не удается поймать процесс нарушения.

Если ваши процессы делают еще несколько интенсивный ввод-вывод в проблемных файлах, то ваш пробег может отличаться. Удачи.

taneli · Accepted Answer · 25 May 2018 в 22:12

Вы могли бы использовать систему аудита для этого. Это немного тяжеловес, но что-то вроде этого должно работать (в /etc/audit/audit.rules):

# delete all other rules
-D

# watch the file in question
-w /path/to/file -p rwxa

, а затем, я думаю, вам нужно перезапустить auditd:

sudo service audit restart

(Если у вас его нет, он находится в пакете auditd.) В этом случае виновник может быть найден в /var/log/audit/audit.log.

Отлично! Это именно то, что я искал. — psusi, 2 July 2011 в 05:24

taneli · Accepted Answer · 25 July 2018 в 22:15

Вы могли бы использовать систему аудита для этого. Это немного тяжеловес, но что-то вроде этого должно работать (в /etc/audit/audit.rules):

# delete all other rules
-D

# watch the file in question
-w /path/to/file -p rwxa

, а затем, я думаю, вам нужно перезапустить auditd:

sudo service audit restart

(Если у вас его нет, он находится в пакете auditd.) В этом случае виновник может быть найден в /var/log/audit/audit.log.

taneli · Accepted Answer · 26 July 2018 в 19:59

Вы могли бы использовать систему аудита для этого. Это немного тяжеловес, но что-то вроде этого должно работать (в /etc/audit/audit.rules):

# delete all other rules
-D

# watch the file in question
-w /path/to/file -p rwxa

, а затем, я думаю, вам нужно перезапустить auditd:

sudo service audit restart

(Если у вас его нет, он находится в пакете auditd.) В этом случае виновник может быть найден в /var/log/audit/audit.log.

taneli · Accepted Answer · 2 August 2018 в 03:43

Вы могли бы использовать систему аудита для этого. Это немного тяжеловес, но что-то вроде этого должно работать (в /etc/audit/audit.rules):

# delete all other rules
-D

# watch the file in question
-w /path/to/file -p rwxa

, а затем, я думаю, вам нужно перезапустить auditd:

sudo service audit restart

(Если у вас его нет, он находится в пакете auditd.) В этом случае виновник может быть найден в /var/log/audit/audit.log.

taneli · Accepted Answer · 4 August 2018 в 19:46

Вы могли бы использовать систему аудита для этого. Это немного тяжеловес, но что-то вроде этого должно работать (в /etc/audit/audit.rules):

# delete all other rules
-D

# watch the file in question
-w /path/to/file -p rwxa

, а затем, я думаю, вам нужно перезапустить auditd:

sudo service audit restart

(Если у вас его нет, он находится в пакете auditd.) В этом случае виновник может быть найден в /var/log/audit/audit.log.

taneli · Accepted Answer · 6 August 2018 в 03:50

Вы могли бы использовать систему аудита для этого. Это немного тяжеловес, но что-то вроде этого должно работать (в /etc/audit/audit.rules):

  # удалять все остальные правила -D # смотреть этот файл -w /  path / to / file -p rwxa

, а затем, я думаю, вам нужно перезапустить auditd:

  sudo service audit restart

(Если у вас его нет, он находится в пакете auditd.) В этом случае виновник можно найти в /var/log/audit/audit.log.

taneli · Accepted Answer · 7 August 2018 в 21:46

Вы могли бы использовать систему аудита для этого. Это немного тяжеловес, но что-то вроде этого должно работать (в /etc/audit/audit.rules):

  # удалять все остальные правила -D # смотреть этот файл -w /  path / to / file -p rwxa

, а затем, я думаю, вам нужно перезапустить auditd:

  sudo service audit restart

(Если у вас его нет, он находится в пакете auditd.) В этом случае виновник можно найти в /var/log/audit/audit.log.

taneli · Accepted Answer · 10 August 2018 в 10:00

Вы могли бы использовать систему аудита для этого. Это немного тяжеловес, но что-то вроде этого должно работать (в /etc/audit/audit.rules):

  # удалять все остальные правила -D # смотреть этот файл -w /  path / to / file -p rwxa

, а затем, я думаю, вам нужно перезапустить auditd:

  sudo service audit restart

(Если у вас его нет, он находится в пакете auditd.) В этом случае виновник можно найти в /var/log/audit/audit.log.

taneli · Accepted Answer · 13 August 2018 в 16:19

Вы могли бы использовать систему аудита для этого. Это немного тяжеловес, но что-то вроде этого должно работать (в /etc/audit/audit.rules):

  # удалять все остальные правила -D # смотреть этот файл -w /  path / to / file -p rwxa

, а затем, я думаю, вам нужно перезапустить auditd:

  sudo service audit restart

(Если у вас его нет, он находится в пакете auditd.) В этом случае виновник можно найти в /var/log/audit/audit.log.

Отлично! Это именно то, что я искал. — psusi, 2 July 2011 в 05:24

Guss · Answer 10 · 25 May 2018 в 22:12

К сожалению, механизм, который использует Linux для мониторинга файлов, isotify, который не предоставляет достаточной информации для извлечения полезных данных: вы получаете только имя файла и действие, которое было выполнено.

ve попытался использовать что-то вроде этого:

sudo inotifywait -mr somedir --format "%w%f" | while read file; do echo -n "$file => ";lsof -b $file; echo ""; done

Слушает, чтобы инициализировать события в указанном каталоге и для каждого запускаемого события lsof, чтобы попытаться поймать процесс, затрагивающий файл. К сожалению, для большинства запросов, которые я тестировал (например, используя редактор для записи в файл), команда LSOF просто замедляется и не удается поймать процесс нарушения.

Если ваши процессы делают еще несколько интенсивный ввод-вывод в проблемных файлах, то ваш пробег может отличаться. Удачи.

Guss · Answer 11 · 25 July 2018 в 22:15

К сожалению, механизм, который использует Linux для мониторинга файлов, isotify, который не предоставляет достаточной информации для извлечения полезных данных: вы получаете только имя файла и действие, которое было выполнено.

ve попытался использовать что-то вроде этого:

sudo inotifywait -mr somedir --format "%w%f" | while read file; do echo -n "$file => ";lsof -b $file; echo ""; done

Слушает, чтобы инициализировать события в указанном каталоге и для каждого запускаемого события lsof, чтобы попытаться поймать процесс, затрагивающий файл. К сожалению, для большинства запросов, которые я тестировал (например, используя редактор для записи в файл), команда LSOF просто замедляется и не удается поймать процесс нарушения.

Если ваши процессы делают еще несколько интенсивный ввод-вывод в проблемных файлах, то ваш пробег может отличаться. Удачи.

Guss · Answer 12 · 26 July 2018 в 19:59

К сожалению, механизм, который использует Linux для мониторинга файлов, isotify, который не предоставляет достаточной информации для извлечения полезных данных: вы получаете только имя файла и действие, которое было выполнено.

ve попытался использовать что-то вроде этого:

sudo inotifywait -mr somedir --format "%w%f" | while read file; do echo -n "$file => ";lsof -b $file; echo ""; done

Слушает, чтобы инициализировать события в указанном каталоге и для каждого запускаемого события lsof, чтобы попытаться поймать процесс, затрагивающий файл. К сожалению, для большинства запросов, которые я тестировал (например, используя редактор для записи в файл), команда LSOF просто замедляется и не удается поймать процесс нарушения.

Если ваши процессы делают еще несколько интенсивный ввод-вывод в проблемных файлах, то ваш пробег может отличаться. Удачи.

Guss · Answer 13 · 2 August 2018 в 03:43

К сожалению, механизм, который использует Linux для мониторинга файлов, isotify, который не предоставляет достаточной информации для извлечения полезных данных: вы получаете только имя файла и действие, которое было выполнено.

ve попытался использовать что-то вроде этого:

sudo inotifywait -mr somedir --format "%w%f" | while read file; do echo -n "$file => ";lsof -b $file; echo ""; done

Слушает, чтобы инициализировать события в указанном каталоге и для каждого запускаемого события lsof, чтобы попытаться поймать процесс, затрагивающий файл. К сожалению, для большинства запросов, которые я тестировал (например, используя редактор для записи в файл), команда LSOF просто замедляется и не удается поймать процесс нарушения.

Если ваши процессы делают еще несколько интенсивный ввод-вывод в проблемных файлах, то ваш пробег может отличаться. Удачи.

Guss · Answer 14 · 4 August 2018 в 19:46

К сожалению, механизм, который использует Linux для мониторинга файлов, isotify, который не предоставляет достаточной информации для извлечения полезных данных: вы получаете только имя файла и действие, которое было выполнено.

ve попытался использовать что-то вроде этого:

sudo inotifywait -mr somedir --format "%w%f" | while read file; do echo -n "$file => ";lsof -b $file; echo ""; done

Слушает, чтобы инициализировать события в указанном каталоге и для каждого запускаемого события lsof, чтобы попытаться поймать процесс, затрагивающий файл. К сожалению, для большинства запросов, которые я тестировал (например, используя редактор для записи в файл), команда LSOF просто замедляется и не удается поймать процесс нарушения.

Если ваши процессы делают еще несколько интенсивный ввод-вывод в проблемных файлах, то ваш пробег может отличаться. Удачи.

Guss · Answer 15 · 6 August 2018 в 03:50

К сожалению, механизм, который Linux использует для мониторинга файлов, isotify, который не предоставляет достаточной информации для извлечения полезных данных: вы получаете только имя файла и действие, которое было выполнено.

вы пытались использовать что-то вроде этого:

  sudo inotifywait -mr somedir --format "% w% f" |  при чтении файла;  do echo -n "$ file = & gt;"; lsof -b $ file;  эхо "";  done

Слушает для инициализации событий в указанном каталоге и для каждого выполняемого события lsof, чтобы попытаться поймать процесс, затрагивающий файл. К сожалению, для большинства запросов, которые я тестировал (например, с помощью редактора для записи в файл), команда LSOF просто замедляется и не удается поймать процесс нарушения.

Если ваши процессы делают еще несколько интенсивный ввод-вывод в проблемных файлах, то ваш пробег может отличаться. Удачи.

Guss · Answer 16 · 7 August 2018 в 21:46

К сожалению, механизм, который Linux использует для мониторинга файлов, isotify, который не предоставляет достаточной информации для извлечения полезных данных: вы получаете только имя файла и действие, которое было выполнено.

вы пытались использовать что-то вроде этого:

  sudo inotifywait -mr somedir --format "% w% f" |  при чтении файла;  do echo -n "$ file = & gt;"; lsof -b $ file;  эхо "";  done

Слушает для инициализации событий в указанном каталоге и для каждого выполняемого события lsof, чтобы попытаться поймать процесс, затрагивающий файл. К сожалению, для большинства запросов, которые я тестировал (например, с помощью редактора для записи в файл), команда LSOF просто замедляется и не удается поймать процесс нарушения.

Если ваши процессы делают еще несколько интенсивный ввод-вывод в проблемных файлах, то ваш пробег может отличаться. Удачи.

Guss · Answer 17 · 10 August 2018 в 10:00

К сожалению, механизм, который Linux использует для мониторинга файлов, isotify, который не предоставляет достаточной информации для извлечения полезных данных: вы получаете только имя файла и действие, которое было выполнено.

вы пытались использовать что-то вроде этого:

  sudo inotifywait -mr somedir --format "% w% f" |  при чтении файла;  do echo -n "$ file = & gt;"; lsof -b $ file;  эхо "";  done

Слушает для инициализации событий в указанном каталоге и для каждого выполняемого события lsof, чтобы попытаться поймать процесс, затрагивающий файл. К сожалению, для большинства запросов, которые я тестировал (например, с помощью редактора для записи в файл), команда LSOF просто замедляется и не удается поймать процесс нарушения.

Если ваши процессы делают еще несколько интенсивный ввод-вывод в проблемных файлах, то ваш пробег может отличаться. Удачи.

Guss · Answer 18 · 13 August 2018 в 16:19

К сожалению, механизм, который Linux использует для мониторинга файлов, isotify, который не предоставляет достаточной информации для извлечения полезных данных: вы получаете только имя файла и действие, которое было выполнено.

вы пытались использовать что-то вроде этого:

  sudo inotifywait -mr somedir --format "% w% f" |  при чтении файла;  do echo -n "$ file = & gt;"; lsof -b $ file;  эхо "";  done

Слушает для инициализации событий в указанном каталоге и для каждого выполняемого события lsof, чтобы попытаться поймать процесс, затрагивающий файл. К сожалению, для большинства запросов, которые я тестировал (например, с помощью редактора для записи в файл), команда LSOF просто замедляется и не удается поймать процесс нарушения.

Если ваши процессы делают еще несколько интенсивный ввод-вывод в проблемных файлах, то ваш пробег может отличаться. Удачи.

Как контролировать, какие файлы открыты

18 ответов

Другие вопросы по тегам:

Похожие вопросы: