Эта команда использует вашу команду для поиска зараженных файлов и передает список в xargs, который запускает выражение в первой строке.
find * -type f -name "*.php" -exec grep -l "cnajwp =" {} \; |
xargs sed -i -E '1s/^(<\?php) \$ocnajwp =.*$/\1/'
Согласно вашему образцу входного файла, это должно сработать.
Так как за это время вы нашли файлы, в которых заражение было размещено несколько иначе, и у вас остались файлы, в которых обе первые строки содержат Php
, вы можете запустить следующее, чтобы очистите эти файлы:
find * -type f -name "*.php" -exec \
gawk -i inplace 'NR==2 && /^<\?php$/ {next} 1' {} \;
Я добавлю сюда еще один ответ для тех, кто увидит это в 2020 году в Debian, поскольку моего решения этой проблемы не было ни в одном из результатов поиска, найденных при поиске в Google строки ошибки «точка монтирования для устройств не найдена».
Фон:
Внезапно понял, что что-то заставило контейнеры рухнуть. Единственная отдаленно вероятная причина, которую я мог придумать, заключалась в том, что я удалил родительскую папку на хосте, в которой подпапка была сопоставлена как том. Другой причиной может быть установка дополнительного физического устройства.
Конечным результатом в любом случае было то, что попытка запустить любой контейнер Docker привела к сообщению об ошибке, показанному в вопросе ("mountpoint for devices not found
" ), и без перезагрузки (и, следовательно, обновления ядра ).
Шаги, которые я предпринял для устранения проблемы, были
journalctl -xn | less
. На самом деле не содержал слишком много дополнительной информации /etc/init.d/docker stop
). /etc/docker/daemon.json
, единственным содержимым которого было{"debug": true}
Эти cgroup
связанные ошибки привели к ответу:
Jan 13 20:17:15 dev-diffia-no dockerd[9022]: time="2020-01-13T20:17:15.964631675Z" level=warning msg="Your kernel does not support cgroup memory limit"
Jan 13 20:17:15 dev-diffia-no dockerd[9022]: time="2020-01-13T20:17:15.964654637Z" level=warning msg="Unable to find cpu cgroup in mounts"
Jan 13 20:17:15 dev-diffia-no dockerd[9022]: time="2020-01-13T20:17:15.964667575Z" level=warning msg="Unable to find blkio cgroup in mounts"
Jan 13 20:17:15 dev-diffia-no dockerd[9022]: time="2020-01-13T20:17:15.964680057Z" level=warning msg="Unable to find cpuset cgroup in mounts"
Jan 13 20:17:15 dev-diffia-no dockerd[9022]: time="2020-01-13T20:17:15.964750643Z" level=warning msg="mountpoint for pids not found"
Jan 13 20:17:15 dev-diffia-no dockerd[9022]: time="2020-01-13T20:17:15.980250151Z" level=debug msg="Cleaning up old mountid : start."
Jan 13 20:17:15 dev-diffia-no dockerd[9022]: Error starting daemon: Devices cgroup isn't mounted
Хорошо, кое-что о cgroups
и монтаже. Это привело меня к обходному пути для другой проблемы cgroups , который можно было бы применить в этом случае, из которых единственными командами, которые, казалось, имели эффект, были
/etc/init.d/docker stop
cgroupfs-mount
/etc/init.d/docker start
Теперь при повторном запуске Docker журналы по-прежнему содержали несколько строк ошибок, связанных с cgroup:
Jan 13 20:24:42 dev-diffia-no dockerd[9775]: time="2020-01-13T20:24:42.258571633Z" level=warning msg="Your kernel does not support cgroup memory limit"
Jan 13 20:24:42 dev-diffia-no dockerd[9775]: time="2020-01-13T20:24:42.258591020Z" level=warning msg="Unable to find cpu cgroup in mounts"
Jan 13 20:24:42 dev-diffia-no dockerd[9775]: time="2020-01-13T20:24:42.258937091Z" level=warning msg="mountpoint for pids not found"
Но половина из них (blkio
,cpuset
)исчезла, и что более важно, следующая строка читалась:
Jan 13 20:24:42 dev-diffia-no dockerd[9775]: time="2020-01-13T20:24:42.259420798Z" level=info msg="Loading containers: start."
И, наконец,
Unit docker.socket has finished starting up.
Таким образом, перемонтирование cgroup решило проблему. Нет необходимости перезагружаться.