Как решить, какой процесс пишет файл

Question

Некоторый процесс на моем производственном сервере, проект, который я унаследовал от другого веб-разработчика, создает ежедневную резервную копию баз данных mysql и файлов сайта. Резервные копии хранятся в /var/www/html/nightlybackup/ и я хотел бы переместить их в /var/www/backups/ а также удалить каталог, который больше не существует, и добавить новый каталог.

Как я могу начать понимать, где определен этот процесс, чтобы я мог внести некоторые изменения?

Я использую Debian 8

Answer 1

"Что попробовать"

Случайная выборка / ковыряться

• Шанс найти виновника: 50%
• Сложность: легко, если вы знаете, на что смотрите

Поищите необычные / неожиданные команды в следующих местах:

• ~/bin любых интерактивных пользователей
• ps -ef (как root) для всего, что вы не знаете, что это такое
• crontab -e для редактирования файла crontab (таблицы cron), чтобы определить, запускается ли он как задание cron каждые X минут / часов / дней.
• ~/.profile или ~/.bashrc любых пользователей
• /usr/local/bin для любых файлов, которые не являются частью управляемого пакета
• /opt
• Примеры языков сценариев: bash, java, perl, python, ruby и т.д. - которые вы еще не запустили или чей PPID (родительский PID) в ps не приводит дерево к процессу, с которым вы знакомы, и знаю, что это не делает
• Посмотрите, не назвали ли они скрипт / исполняемый файл так же, как каталог: find / -iname \*nightly\* (может вернуть много ложных срабатываний, поэтому, возможно, было бы целесообразно добавить | less )

Есть множество других способов сделать это, например, с сервера приложений Java, CGI-скрипта Perl и т.д., Но это только начало.

Hackish Quick-n-Dirty Полунадежный метод опроса

• Вероятность найти виновного: 95%
• Сложность: легко (просто запустите этот скрипт, который я взломал вместе за 5 минут)

nohup lsof -r 2 +D /var/www/html/nightlybackup 2>&1 | gzip > nightlybackup-writers.txt.gz &

Короче:

• nohup предотвращает выход из командной строки при закрытии терминала или сеанса SSH.
• lsof "выводит список открытых файлов" и делает это рекурсивно в каталоге (+D), повторяется бесконечно (-r) и обновляется каждые 2 секунды.
• gzip результаты, если вы получаете много, чтобы предотвратить быстрое заполнение вашего диска.
• Вы можете просмотреть результаты с помощью команды zless .

Эта команда может оказать значительное влияние на производительность, особенно на (1) старых ядрах или (2) системах на жестких дисках. Так что запустите его на короткое время и определите, сколько ЦП / диск он использует, и, если это слишком много, убейте процесс.

Вам придется оставить его работающим во время выполнения ночного резервного копирования. Обычно это относится к любому механизму, который может надежно обнаружить эту программу.

Ultimate Швейцарские Армейские Ножи

• Вероятность найти виновного: 99,999999%
• Сложность: экстремальная (требуются знания уровня разработчика ОС, или вам повезет, и вы скопируете готовый скрипт, который делает то, что вы хотите)

Как DTrace, так и SystemTap являются отличными инструментами для мониторинга системы на предмет определенного вида деятельности. DTrace, возможно, лучше, но многие люди думают, что это сбой или что SystemTap лучше, потому что он "родной" для Linux (DTrace был добавлен позже, после того, как изначально был разработан для Solaris).

Вы можете создать команду / скрипт DTrace или SystemTap, чтобы определить, кто пишет по любому пути в этом каталоге. Вот пример сбоя сервера, а также полезная ссылка на ряд однострочников DTrace. Затем просто запустите его в фоновом режиме (например, через screen или nohup) и подождите, пока не появятся резервные копии, и вы получите имя процесса и PID.

Если у вас нет руткита, и этот руткит предназначен для маскировки его активности из DTrace/SystemTap, и при условии, что вы правильно понимаете команду DTrace или SystemTap, это БУДЕТ найти, что делает. Но это также самый сложный метод.