Почему перенаправление sed-вывода на тот же входной файл делает мою машину неактивной?
Я использовал «aptitude» для обновления / обновления 15.04 и столкнулся с некоторыми проблемами.
в кеше много места, в результате чего ошибки «закончились», некоторые из основных компонентов Touch Ubuntu были удалены в процессе - оставив телефон полезным только в терминальном режиме, но без приложений с сенсорным экраном 3) Обновление apt-get6 показалось вам приятным, но после обновления 3G / 2G-носитель больше не обнаруживался. Это можно легко решить, изменив режим несущей с 3G на 2G и обратно =>, что приведет к повторному сканированию доступных носителей - в результате снова появится рабочий телефон :), поэтому просто предупреждение ... используйте apt-get тщательно ... вся система все еще находится в бета-версии, и это, похоже, приводит к некоторым из этих поведений.
2 ответа
Ваша команда sed пыталась прочитать файл, к которому он добавлялся. Он никогда не достигнет конечного файла, но будет много попыток процессора. Вот почему был изобретен ^ C (процесс прерывания).
-
1Я не думаю, что ^ C был вариантом там ... он пошел к HALT, то есть не мигающий курсор, застрял! – Έρικ Κωνσταντόπουλος 7 July 2016 в 12:41
Добавление обратно к файлу, который вы читаете, ни в коем случае не является хорошей идеей, так как у вас будет постоянно растущий файл. Если вы действительно хотите записать обратно в файл, вы должны использовать флаг -i:
sed -i 's/original/edited/g' file.log
или если вы хотите создать резервную копию перед выполнением изменений, вы можете добавить суффикс файла к [ f4]:
sed -i.bak 's/original/edited/g' file.log
Это создаст файл с именем file.log.bak, а затем выполнит изменения, что вы там сделали, пытаясь добавить к файлу, который вы читаете, мы вызываем в программист сленг a расы данных, в которых разные процессы участвуют в том же источнике данных, что и вход или выход. Вот почему ваша машина остановилась.
-
1Я удивлен, что это принятый ответ, потому что он даже не адресует вопрос OP "I really would like to understand why the execution of that command was able to make the system so unresponsive, and if mechanisms exist at the system level to trigger alerts and kill the offending process?" – Steve 7 July 2016 в 23:59
-
2@Steve Из-за того, почему это остановилось, я обратился, но для второй части вы правы. Я не обращался к этому, потому что я не знаю ответа на это. Мы протестировали команду после широкомасштабного обсуждения чата и пришли к совершенно другим результатам на разных машинах и операционных системах. Пример. На машине с аркой это позволяет только файлу расти навсегда, но не делает машину неактивной. На моей машине Ubuntu я получал тот же результат, что и вопросник, не имея возможности убить процесс. Вторая машина, тестирующая то же самое в VM Ubuntu, остановилась. – Videonauth 8 July 2016 в 01:44
-
3[F1] всего процесса с другой стороны didtn воспроизводит результат и это на моей машине и на машине другого пользователя. Конечно, есть механизм, с помощью которого вы можете убивать невосприимчивые приложения, но если ваша машина не реагирует, вы остаетесь только одним вариантом, сбросив ее. Я все еще тестирую это, и, прежде чем я не полностью пойму, что вызывает описанное поведение, я не могу решить эту часть вопроса. – Videonauth 8 July 2016 в 01:44
-
4Вероятно, это разница в конфигурациях ядра, как и другой планировщик, который определяет приоритеты IO или различия в драйвере диска / файловой системы между системами. Приятно видеть расследование, которое вы, ребята, сделали, это хорошая информация. – Steve 8 July 2016 в 05:09
-
5Если вас интересует другая точка данных; Я попробовал это на машине CentOS с довольно маленьким файлом, и он сделал то же самое, что и мое решение для губки ниже. Я предполагаю, что для небольшого файла sed будет храниться все содержимое в памяти, а затем закрывается, а не удерживается. С файлом ~ 100 МБ, как и в OP, он рос бесконечно, но не кирпичи машины. – ymbirtt 8 July 2016 в 10:23