Люди, які не розуміють Термінал, часто бояться його використовувати, побоюючись, що вони можуть зіпсувати свою команду і зламати комп'ютер. Ті, хто краще знає Термінал, знають, що це не так - зазвичай Термінал просто видасть помилку. Але чи є насправді команди, які зламають ваш комп’ютер?

ПОПЕРЕДЖЕННЯ: ви можете втратити дані, ввівши ці або скопіювавши пасту, особливо sudoта rmкоманди.

Один із способів зірвати комп’ютер - це виконання так званої вилки-бомби .

Ви можете виконати його на unix-sytem:

:(){ :|: & };:

Це команда, яка буде рекурсивно нерестувати процеси, поки ОС не буде настільки зайнята, що більше не реагуватиме на жодні дії.

Не впевнений, що ви маєте на увазі під час збою комп'ютера - якщо ви переформулюєте його, щоб сказати "зробити комп'ютер непридатним", то так. Безумовно, все, що потрібно, - це одна блукаюча команда - лише момент, коли ти не думаєш чітко про те, що робиш, подібно до того, коли ти говориш, не думаючи, і шкода може бути величезною і майже негайною. Класичний приклад:

$ sudo rm -rf /

Якщо ви дозволите цій команді виконуватись ще лише одну секунду, це може знищити достатню кількість вашої системи, щоб зробити її незавантаженою і, можливо, призвести до незворотної втрати даних. Не робіть цього.

Припустимо, ви не знаєте, чим займаєтесь та намагаєтесь зробити резервну копію якогось жорсткого диска

dd if=/dev/disk1 of=/dev/disk2 

Добре, якщо ви змішаєте їх (перемкніть, якщо і на), вони замінять свіжі дані зі старими даними, запитань не задається.

Подібні поєднання можуть статися з утилітами архіву. І відверто кажучи з більшістю утиліт командного рядка.

Якщо ви хочете, щоб приклад суміші з одним символом, що призведе до аварійної роботи вашої системи, подивіться на цей сценарій: Ви хочете перемістити всі файли в поточному каталозі в інший:

 mv -f ./* /path/to/other/dir

Приймемо той факт, який ви навчились використовувати ./для позначення поточного каталогу. (Я так) Добре, якщо ви опустите крапку, вона почне переміщати всі ваші файли. Включаючи ваші системні файли. Вам пощастило, що ви цього не судили. Але якщо ви десь прочитали, що за допомогою "sudo -i" вам більше ніколи не доведеться вводити sudo, ви зараз увійшли як root. А тепер ваша система їсть сама перед вашими очима.

Але я знову думаю, що такі речі, як перезапис моїх коштовних файлів коду сміттям, тому що я переплутав один символ або тому, що я змішав порядок параметрів, - це більше клопоту.

Скажімо, я хочу перевірити код асемблера, який генерує gcc:

gcc -S program.c > program.s

Припустимо, у мене вже було program.s і я використовую завершення TAB. Я поспішаю і забуваю двічі TAB:

gcc -S program.c > program.c

Тепер я маю код асемблера у своєму program.c і більше немає коду c. Що для декого є принаймні справжньою невдачею, а для інших - часом починається з нуля.

Я думаю, що це ті, які завдадуть реальної «шкоди». Мені дуже не байдуже, якщо моя система виходить з ладу. Я б переймався втратою моїх даних.

На жаль, це помилки, які доведеться робити, поки ви не навчитесь користуватися терміналом з дотриманням відповідних заходів обережності.

Викликання паніки в ядрі є більш схожим на збій, ніж інші відповіді, які я бачив тут поки що:

sudo dtrace -w -n "BEGIN{ panic();}"

(код взятий звідси і також знайдений у власній документації Apple )

Ви також можете спробувати:

sudo killall kernel_task

Я не перевірив, що другий там насправді працює (і я не маю наміру, оскільки зараз я відкриваю якусь роботу).

Сучасний macOS робить дуже важким збій вашої машини як непривілейованого користувача (тобто без використання sudo), оскільки системи UNIX призначені для обробки тисяч користувачів, не дозволяючи жодному з них зламати всю систему. Тож, на щастя, зазвичай вам потрібно буде запропонувати перед тим, як зробити щось, що руйнує вашу машину.

На жаль, цей захист стосується лише самої системи. Як показує xkcd, існує багато речей, які вам не важливі, але не захищені Захистом цілісності системи, привілеями root або паролем:

Отже, ви можете ввести багато речей, які просто зірвуть ваш обліковий запис користувача та всі ваші файли, якщо ви не будете обережні. Кілька прикладів:

• rm -rf ${TEMPDIR}/*. Це здається цілком розумним, поки ви не зрозумієте, що змінна середовища написана TMPDIR. TEMPDIRзазвичай не визначений, що робить це rm -rf /. Навіть без sudoцього це з задоволенням видалить усі дозволи, які ви маєте на видалення, що зазвичай включатиме всю вашу домашню папку. Якщо ви дозволите цьому запуститись досить довго, це також запустить будь-який накопичувач, підключений до вашої машини, оскільки у вас зазвичай є права на запис на них.
• find ~ -name "TEMP*" -o -print | xargs rm. findзазвичай знайде файли, що відповідають певним критеріям, і роздрукує їх. Без -oцього робиться те, що ви очікували, і видаляється кожен файл, починаючи з TEMP*( поки у вас немає пробілів на шляху ). Але, -oозначає "або" (не "виводити", як це робиться для багатьох інших команд!), В результаті чого ця команда фактично видаляє всі ваші файли. Бампер.
• ln -sf link_name /some/important/file. Я час від часу отримую синтаксис для цієї команди неправильно, і він із задоволенням замінить ваш важливий файл марним символічним посиланням.
• kill -9 -1 знищить кожну вашу програму, досить швидко вийде з системи та, можливо, спричинить втрату даних.

Ще одне, що ви можете зробити (що я раніше робив помилково):

sudo chmod 0 /

Це зробить вашу всю файлову систему (що означає всі команди та програми) недоступною ... за винятком кореневого користувача. Це означає, що вам потрібно буде увійти безпосередньо як користувач root і відновити файлову систему, Але ви не можете отримати доступ до sudoкоманди (або будь-якої іншої команди з цього приводу). Ви можете відновити доступ до команд та файлів, завантажившись в однокористувацький режим, встановивши та відновивши файлову систему за допомогою chmod 755 /.

Якщо це робити рекурсивно, chmod -R 0 /тоді це зробить систему непридатною. Правильним виправленням у цьому пункті є використання Disk Utility з розділу відновлення для відновлення дозволів на диск . Можливо, вам буде краще просто відновити знімок або резервну копію вашої файлової системи, якщо це було запущено рекурсивно.

Відповіді на дзвінок sudoслід вважати недійсними. Вони вже передбачають адміністративний доступ до системи.

Спробуйте perl -e 'exit if fork;for(;;){fork;}'. У OSX зараз може бути якась гарантія проти цього. Якщо представлено яблучну бульбашку з запитанням, чи потрібно вимкнути додаток Terminal і підпроцеси, ви (майже) хороші.

while true ; do cat /dev/zero > /dev/null & doneтакож дуже зручно, особливо якщо у вас немає perl.

for i in 1 2 3 4 ; do cat /dev/zero > /dev/null & doneпросто зробить маленький кумедний тест на завантаження процесора. Дуже добре для перевірки, чи радіатор і вентилятор не відповідають номіналу.

Звичайно, переконайтеся, що у вас є резервна копія та збережіть усі важливі вами файли, а потім введіть halt

Якщо припустити, що ви використовуєте sudoкорінь, Mac вийде з ладу.

Найбільший ризик командного рядка - втрата даних. Інтерфейс macOS розроблений протягом десятиліть, щоб не дивувати людей і не роздрібнювати їх дані, налаштування чи програми. Графічний інтерфейс macOS також існує, щоб прибрати криву навчання (круту), щоб бути безпечною та освоїти сценарій оболонки.

Ви втрачаєте ці засоби захисту, тому я застерігаю людей, починаючи з терміналу або ssh. Якщо у вас є резервна копія, яку ви знаєте, працює і маєте час і впевненість / вміння виконати відновлення, тоді вам слід зануритися і навчитися і навіть розбити речі.

sudo kill -9 -1  

Я випадково виконав kill -9 -1perl-скрипт, що працює як root. Це було так само швидко, як тягнення шнура живлення. Після перезавантаження сервер здійснив перевірку файлової системи та продовжив належну роботу.

Я ніколи не пробував цю sudo kill -9 -1команду в командному рядку. Це може не працювати, оскільки ідентифікатор процесу "-1" означає "знищити всі процеси, що належать до групи процесів абонента".

Не впевнений, якщо з sudo, це також означає init та всі ядра ядра ... Але якщо ви корінь, kill -9 -1обов'язково зробите негайну зупинку - як і витягування шнура живлення. До речі - у журналах нічого не з’явиться, бо ця команда - найшвидший вбивця на заході!

Власне, щоб видужати, я пішов до наших сисадмінів і сказав їм, що я зробив. Вони зробили важку перезавантаження, тому що не було можливості ввійти на цей сервер (RHEL6).

Як kill -9 -1корінь вбиває кожен процес, який працює як корінь. Тобто тобто sshd. Це негайно вийшло з мене і заважало комусь знову входити. Будь-який процес, розпочатий init - включаючи init, був убитий, якщо вони не змінили UID або GID. Навіть увійти через серійну консоль вже не було можливо. ps -eaf | grep rootпоказує деякі фантазійні процеси, які, якщо вони реагують на SIGKILL за замовчуванням, в значній мірі зупинять навіть базові записи на HD.

Я зараз не спробую цього на своєму ноутбуці :-) Мені не цікаво дізнатися, чи kill -9 165дійсно ([ext4-rsv-conver]) перестане писати на HD.

Так, ви можете повністю знищити вашу систему. Випадково зробити щось з sudoпривілеями - це один із прикладів, який виклав, будь то забуття кількох символів, які доручають терміналу зробити щось зовсім інше, ніж ви задумали. rming /замість /tmp/\*лише 5 різниць символів. Розміщення місця в неправильному місці може також зробити щось зовсім інше. В інших випадках, здавалося б, добре значущі інструкції можуть містити в ньому шкідливий код. Деякі люди в Інтернеті дуже добре обманюють код.

Також є команди, які за допомогою html можуть зробити нульовий розмір шрифту, тож щось абсолютно нешкідливе виглядає, коли копіюється в буфер обміну, насправді може бути встановлення чиїхось git repo як надійного джерела та завантаження зловмисного програмного забезпечення.

І є команди, які ви можете запустити, які відкривають вас для експлуатації, або які можуть бути ідеально сприятливими, але видаляють важливі файли чи програми або пошкоджують ваш диск. Насправді, неправильне використання інструментів може зробити щось настільки ж базове, як випадкове записування у ваш завантажувальний сектор, у голову вашого диска чи багато інших проблем.

Прикладом чогось менш руйнівного, що не було розміщено, є відкриття бінарних файлів у vi. Якщо ви коли-небудь пробували це, ви знаєте, що він може зіпсувати ваш термінал до того, що він непридатний, поки він не стане reset.

Крім того, існують команди, які заблокують вашу машину, наприклад:

yes >> /dev/null & yes >> /dev/null & yes >> /dev/null & yes >> /dev/null & 

Ви можете спробувати це, він не заподіює шкоди, але він заблокує ваш процесор, і вам доведеться вбивати кожен процес, який ви породили.

За словами, в обчислюванні прийнято вважати, що не можна робити омлет, не розбивши кілька яєць. Вам слід бути обережними в терміналі, але єдиний спосіб покращити використання ОС - це навчання та практику.

Я лише початківець баш, але ви могли встановити час True; робити КОМАНД; зроблено; Більшість людей спробують Ctrl + C, що зупинить команду, а не зовнішній процес (ctrl + Z, який потім потрібно вбити). Я здогадуюсь, що якщо команда - це якась важка операція, як множення великої кількості на власну силу, то це може зіпсуватись із вашими ресурсами. Але дійсно, сучасна ОС зазвичай захищена від такого безладу.

Звичайно, ви все одно можете викликати збій системи за допомогою команд, введених разом з терміналом.

З роками стає важче, мабуть, через всілякі обмеження та захисні заходи, які застосовуються, але, як стверджує закон Мерфі: "Ніщо не є надійним для дурного".

"Бомби на вилках" і все те, rm -rfщо стосується дітей із сценарію, - це давно відомі речі для UNIX. За допомогою Mac OS X ви можете розважитися, скориставшись його частинами підсистеми графічного інтерфейсу ( WindowServerзгадавши) або чимось на зразок брандмауера OpenBSD, PFякий інженери Apple внесли, але так і не встигли оновити з 2008 року. PFпрацює в ядрі так , коли він ловить примху цього час Apple , каже вам « ви перезавантаження комп'ютера з - за паніки» або речі , як це.

Найгірше - це те, що ти ніколи не можеш уявити, де-чому-чому панікувала - тому що Apple не надає значущих слідів стека; ви можете мати лише шістнадцяткові номери зворотних адрес кадру стека.

Трохи неоднозначно, що ви маєте на увазі під «збоєм» вашого комп’ютера ... і для цього немає однозначної правильної відповіді, хоча в інших відповідях є корисні приклади. Оскільки ваше запитання є більш неоднозначним та загальним, я хотів би зупинитися на природі питання та дати більш загальну відповідь.

Люди, які не розуміють Термінал, часто бояться його використовувати, побоюючись, що вони можуть зіпсувати свою команду і зламати комп'ютер

Я вважаю, що командний рядок - це двосхилий меч, і часто дуже гострий. Його найбільшою силою є також його найбільша слабкість для нових користувачів: програми CLI роблять те, що ви говорите, не запитуючи, чи це дійсно те, що ви мали на увазі. Вони часто не просять підтвердження, не надають ручну чи інтерактивну допомогу, а їх варіанти короткі, часто стислі, іноді заплутані в текстових рядках. Зауважте, що вони, як правило, дуже добре задокументовані, потрібно лише прочитати посібник (що майже завжди man <command you are about to run>) і витратити час, щоб зрозуміти, що буде робити командний рядок, який вони будуть виконувати.

Цей режим роботи є потужним - це означає, що досвідчені користувачі CLI можуть створювати довгі команди "конвеєри", які виконують складні завдання за допомогою окремих команд. Це тому, що завдання не запитає "Ви впевнені?" кожен крок шляху, він робить те, що йому сказано. Але для користувача, незнайомого з цим режимом, і звичного до графічного інтерфейсу, де допомога в Інтернеті за один клік , незнайома і страшна.

Але чи є насправді команди, які зламають ваш комп’ютер?

Чи можете ви "зламати" комп'ютер за допомогою CLI? Може бути. Ви безсумнівно можете викликати втрату даних, якщо неправильно використовувати деструктивну команду. EG багато відповідей тут згадують rm, команду, яка видаляє файли. Очевидно, що ви можете викликати втрату даних за допомогою цієї команди, це те, що команда була розроблена.

Як вказували інші відповіді, ви можете використовувати командний рядок, щоб зробити вашу машину практично непридатною протягом певного періоду часу: ви можете вимкнутись без підтвердження, викликати процес використання 100% наявних ресурсів без підтвердження, вбити всі ваші програми або знищити вашу файлову систему. Якщо ви дійсно цього хотіли, ви можете використовувати CLI для створення розширення ядра, яке спричиняє паніку ядра (що є найближчим до "аварії", про яку я можу придумати).

Командний рядок (доступ до якого здійснюється через Термінал) - це потужний інструмент. Часто вирішити проблему за допомогою Terminal швидше, ніж GUI. Деякі рішення доступні лише за допомогою команд Terminal. Однак ключовим для CLI є розуміння . Не виконуйте випадкові команди, які ви бачите в Інтернеті. Прочитайте сторінки чоловіка і зрозумійте, що виконують команди. Якщо ви не впевнені, запитайте когось або дізнайтеся більше про команду, перш ніж виконувати її.