En büyük komut satırı hatası? [kapalı]


35

Tek bir yanlış / yanlış yazılmış / yanlış yönlendirilmiş komut satırında şimdiye kadar verdiğiniz en büyük zarar (ne tür)? Örneğin, bir üretim sistemi veritabanını yanlışlıkla geri sildim, fakat şanslıydım (yani yedeklenmiş) ve kalıcı veri kaybı, para kaybı, mülk hasarı vb.

En önemlisi (oy için), bir daha asla olmayacağından emin olmak için ne yaparsın?


9
Bu bir anket olduğu için CW olmalı
Eddie

Öyleyse neden varsayılan olarak CW'leri yoklamıyor?
Luke,

4
Progmatik bir anket olduğunu nereden bilebilirler?
Mikeage

1
Mekanizma SO'larla aynıysa, bir soruyu düzenleyebilseniz bile, onu CW olarak değiştiremezsiniz. Bunu sadece OP veya moderatör yapabilir.
kaos

9
İyi fikir - tüm yıkıcı hatalarınızı, gelecekteki tüm işverenlerin görmesi için internette herkese açık olarak yayınlayın! :)
Sam Schutte

Yanıtlar:


46

SQL server'da, bir üretim sisteminde:

update customer set password = '' <enter>

En yeni yedek bir haftalık gibiydi.

Bunu hafifletmek için, şimdi selectilk önce wherecümleyi doğru yaptığımdan emin olmak için ilk önce bir bildiri yazıyorum , sonra geri dönüp bu setmaddeyi ekleyip deyimi değiştirmek için düzeltiyorum update.


11
Ahh. Diğer bir seçenek 'BEGIN TRANSACTION'; Geri çekilebileceğini bilmek güzel. :)
Murali Suriar

5
İkisinin birleşimi, kaç tane güncelleyeceğimi düşündüğümü görmek için count (*) seçeneğini seçin ve ardından güncellemeyi yapmak için işlemde güncelleme yapın. Sayımlar eşleşirse, geri alma ve neden olmadığını anlayın. Tabii ki, "basit" güncellemeler için bunu yapmam ve bunlar hep sizi mahveder. :-)
WaldenL

Suçlu, kendim yaptım :(
Jim OHalloran

8
Canlı bir sistemde (veya başkaları tarafından da kullanılan bir test sistemi) BEGIN TRANSACTION ile dikkatli olun - yakında COMMIT veya ROLLBACK yaptığınızdan emin olun, aksi halde işleminizin kilitlendiği kaynakları kilitlemek için bekleyen diğer işlemleri kilitlenme ile sonuçlayabilirsiniz.
David Spillett

Bazı sistemlerde yapabilirsiniz; <enter>
J. Polfer

37

En büyük hata? Düşünmediğimde iki değişken koyduğumu düşünüyorum. Böylece rm -rf $ VARIABLE / $ VARIABLE2, rm -rf / oldu. FreeBSD kısa süre önce rm aracını güncelledi, böylece rm -rf / bu hata nedeniyle tam olarak mümkün değil!


4
Ben, rm'nin çalışma şeklini değiştirmenin nedeni olduğumu söyleyen cümleimi tekrar okumak istiyorum , durum böyle değil. Görünüşe göre insanlar komut dosyalarında rm kullanıyorlardı ve aynı şey oldu ve başarısız bir güvenlik eklemek istediler.
X-Istence,

3
oyumu geri
çekerim

Bir keresinde bir erkeğin rm -rf / usr / local / junk yaptığını gördüm.
Satanicpuppy

Peki ya "rm -rf /" yerine "rm -rf / *"? Şimdi
BSD'ler

26
shutdown -h now 

yerel iş istasyonu için tasarlandı, ancak üretim sunucusunda ssh aracılığıyla oturum açarken yazdı. O zamandan beri her zaman benim ana bilgisayar adı var $PS1.


En azından muhtemelen hiçbir veriyi kaybetmezsin ...
Zifre

Doğru, ama bu çok uzun zaman önceydi, IPMI ya da KVMoIP henüz popüler değildi. Oraya gidip düğmeyi çevirmek için teknisyeni ele geçirmek zorunda kaldık.
vartec


Yerel iş istasyonlarında bile, her durumda "+1" kullanıyorum.
msanford

3
Ana bilgisayar adını istemde kullanırdım, ancak şimdi komutun yürütülmesinden önce geçerli makinelerin adını girmemi istemek için kapatma (ve ilgili - halt et al) komutlarını yattım. Bu sadece yanlış sunucuyu kapattığımı fark etmem için gereken ek adımı veriyor. Sorun şu ki, o yamayı bir kez uyguladıysam, bir daha asla yapmadım - ama iş arkadaşlarımdan birkaçını kurtardı :)
Moo

26

-R'yi bir kapatma komutundan çıkarmak. Uzak bir sunucuda. Ülkenin diğer tarafında. Uzak ofiste BT personeli yok.

Hepimiz yaptık, bu aşamada neredeyse bir geçiş ayinine benziyor.


25

Bir VMS sisteminde, mantıksal isimler atamak için ASSIGN DCL komutunu kullanıyordum ve önceki bir ASSIGN komut satırını GERİ ALMAK istedim. Şimdi, VMS'de, komutun açık olmasını sağlamak için yalnızca bir komutun birçok karakteri yazdınız. Bu yüzden yazmak istedim

REC ASS

ama yanlışlıkla yazdım

Req ASS

yerine. REQ, operatör ayrıcalığına sahip olan herkesi (IT'deki herkes) tartışmayı yayınlayan REQUEST komutu için yeterince belirgindi. Böylece tüm bölüm, benim "sadece ASS" olan yayın mesajımı aldı.


Hilarious :-) :-)
Ludwig Weinzierl

1
Hepimizin bildiği gibi, tüm Yazılım Sucks. Neden BT’de birisi bunun başka bir şey ifade ettiğini düşünüyor?
Adriano Varoli Piazza

24

Solaris sisteminde: "killall dataLoader".

'dataLoader' üzerinde çalıştığım bir uygulama. Linux'ta killall pkill gibi çalışır. Argüman olarak verilen bir dizgeyle eşleşen işlemlere bir sinyal gönderir. Solaris'te, mevcut kullanıcının öldürebileceği sistemdeki her şeyi öldürmeyi dener. Ben kökündüm.


orada bulundum, yaptım ...
James

2
Aynen iki hafta önce Power 5 AIX 6 sisteminde aynı şeyi yaptım ... Tamam, tam olarak değil, bir "killall -9 java" yaptım :)
Andor

3
@Andor: Kesin olarak öldürdün java. ;)
Bobby

16

Bir zamanlar, birçok ay önce, belirli bir çalıştırılabilir dosyayı bulmam gerekiyordu ancak isminin tam adını hatırlayamıyordum (ancak birkaç harfini hatırlayabiliyordum). Böylece / usr / bin dizinini böyle bir şeyle kontrol edeceğimi düşündüm.

rm /usr/bin/i*g*

Garip. Hiçbir şey geri dönmedi. İkinci mektubu daha önce yanlış hatırladığımı düşündüm, tekrar denedim.

rm /usr/bin/i*

Yine, hiçbir şey. / Usr / local / bin, / usr / sbin ile aynı şeyi yaptıktan ve içinde olabileceğini düşündüğüm herhangi bir şeyi yaptıktan sonra, 'ls' komutunu yanlış yazdığımı fark ettim.

Beyin fırtınasının nereden geldiğini tam olarak bilmiyorum, ama kesinlikle bir daha yaptığım bir hata değil.


Bu, ls / etc / bir şey, Ctrl + r, Ctrl + a, Del, Del, kedi, Enter gibi yolları yeniden kullanırken dikkat edilmesi gereken bir şeydir.
Alex,

8
Sunucumda bile hiçbir şey döndürmüyor.
Mircea Vutcovici


16

Nokta dosyaları da dahil olmak üzere bir dizindeki her şeyin sahipliğini değiştirmeye çalışıyorum:

chown -R user * .*

Tahmin et ne olduğunu mu?


10
posta okumak -gerçekle hızlı ???
Wiren

5
Orada, bu bana öğretti. [^.] * Desen gerçekten çok iyi
Maciej Pasternacki

1
@chaos: Komut şu anki dizininizdeki ve hatta nokta dosyalarınızdaki her şeyi kaldırıyor gibi görünüyor
Léo Léopold Hertz 준영

2
@chaos: O mu değil kaldırmak .. ve sahip asla ve asla. Sen sadece yanılıyorsun. Lütfen, bu davranışa sahip olan (hiç görmediğim ve 7. basım unix gibi süper antika unix'lerin bile davranışı olmadığı belgelenen) tek bir unix uygulamasından bahsedin.
chris

1
./.* bunu engeller mi yoksa yine de dizin ağacını ./../ üzerinden geri mi geçirir?
tj111

15

/ Dev / sdb'yi imha etmek istemiştim, neyse ki iyi bir yedekleme yaptım

dd if=/dev/urandom of=/dev/sda

Bunu bir kez (/ dev / zero dışında), bir Linux sunucusunun kök bölümünü yok etti, hepsini aynı sunucudan geri kopyalayarak kurtardı.
Marius Gedminas

14
select * from <File1> join <file2>

Bir üretim kutusunda. Bir onmaddenin eksikliğine dikkat edin . :-) Her iki masa da multi-milyon satırlık masalardı ve bu, 90'lı yılların ortalarında bir AS / 400'deydi ve SQL bir kez çalıştığında onu öldüremedi.


14

Veri üretim sunucumuzun birinde köklerimden biri şöyle yazıyor:

chmod -R777 /

Çünkü bazı senaryolarda izin hatası alıyordu ...

Bundan kısa bir süre sonra, özel anahtarı tüm sunuculardan kaldırıldı ve veri üretim sunucusundaki 1 TB veri geri yüklemesine özen gösterdi ...


12

Benim favorim üniversitedeykendi. Bir uygulama inşa ediyordum (ne olduğunu hatırlamıyorum) ve kök olmadığım için onu oluşturdum

PREFIX=~username/usr/local

Böylece onu ev dizinime yükleyebilirim. Ne yazık ki içine yüklü

/home/username/src/app/~username/usr/local

yerine. Doğal olarak yeniden başlattıktan sonra silmek için idam

rm -rf ~username

Kaynak dizinde.

Neden bu kadar uzun sürdüğünü merak ettim ....

:-)

Ancak en kötüsü, solaris iş istasyonuyla çalışırken ve tüm kurulumları yaptıktan sonra yapılandırmayı canlı yapılandırma için hazır hale getirmek istedik. Bu yüzden idam

sys-unconfig

Uyarı mesajı kabul edildi ve makine yeniden başlatılıp yerine "fabrika varsayılanlarına" geri dönüyordu.

connection closed by foreign host.

Hikayenin ahlaki Asla başka bir ana bilgisayarda kök kabuğu bırakma! HİÇ !!


Ben kendim PS1'de hostname için gidiyorum. Bir noktada, yerel ve uzak girişler için farklı renkler kullandım (ayrıca kullanıcı / kök için de farklı renkler).
Marius Gedminas

12

Yıllar önce, projenin sorumlusu olan bir arkadaşımla bir proje üzerinde çalışırken php'de bazı şeyleri kodluyordum. İşbirliği çabası içinde birbirimize IM' yapıyorduk. Biz her zaman oyunda ileri geri şaka yapıyoruz.

PHP’de dini bir Perl savaşı çekerken ssh-agent’ın makinemde düzgün çalışmasını sağlamaya çalışıyordum. Sonra ssh-acentası hakkında değerlendirilmesi gereken bir şeyden bahsettim (neden bunu söylediğimden emin değilim). Sonra bana bu mesajı bir çaba ile gönderdi, bu yüzden, sorunumda bana yardım etmeyi düşündüğümü düşündüm.

\# eval $(echo ssh-agent | 
perl -pe 's/h-a/m -r/' | 
perl -pe 's/^ss/r/' | 
perl -pe 's/gent/f \//')

UYARI! KOMUTAN ÇALIŞMAYIN !!!

Değerlendirmeyi kaldırır ve iç komutu kendi başına çalıştırırsanız:

rm -rf /

Neler olduğunu farketmem 4 saniyemi aldı, ancak hasar çoktan bitmişti. İşletim sistemimi yeniden kurmak zorunda kaldım. Neyse ki, / etc iirc içindeki bazı şeyler dışında işimden hiçbir şey silinmedi. Ona neden yaptığını soran bir korku mesajı gönderdiğimde kocaman bir kahkaha attı. İkimiz de uzun vadeli sistem mühendisiyiz. Koşacağımı ve basitçe c & p'ing yapmadan önce kontrol etmek için daha dikkatli olacağını düşünmüyordu ve ona güvenmiştim, o yüzden oynamayı bile düşünmemiştim. Söylemeye gerek yok, bu küçük hikaye aramızda her zaman gelir. Böylece ölümsüzleştirmeye karar verdim.

Bunun tekrar olmasını nasıl azalttım? Ben kimseye güvenmiyorum!

Daha az ilginç olan bir hikaye ise birkaç yıl önce işte kritik bir görev kutusunda biraz iş yaptığımdı. Farklı makinelere açık bir kaç terim vardı. Bir dizindeki gereksiz şeyleri kaldırmam gerekiyordu. Eh, şartlarımda kayboldum ve yanlışlıkla çektim . benim yerel dir ama yanlış ana (yanlış terim) !!. Komutu uygulama sunucusunda / var / yerine / var / lib / mysql dizininde (farklı terim) yürüttüm. Söylemeye gerek yok, üretim veritabanını sildim. Neyse ki, ben ve bir meslektaşım birincil olanı yedeklemelerden ve bekleme modundan yeniden inşa ederken çevrilen sıcak bir bekleme durumumuz vardı. Bu yapmak için yaklaşık 18 saat sürdü.

Azaltma: çalıştırmadan önce hangi pencereleri çalıştırdığımı bilmemize dikkat edin.


İş yerimizde, kullanıcı adlarımızı bash olarak benzersiz renklerde görüntülemek için tüm sunucularımızın .bashrc dosyasını yapılandırdık. Bu sayede her zaman hangi makinede olduğunuzu anında görürsünüz. (Tamam, belki 20-30 makineden daha fazla managin yaparken bu bir problem olabilir ... Ama yine de çok kullanışlı.)
fgysin Monica

Hiç kimse için +1 güven.
Wayne Werner

11

kısa versiyon

#/bin/bash
$0&
$0

Buna değer, eğer bunu kök olarak yapmazsan, koşkill -9 -1
BCS

3
bu ne yapar?
Nathan DeWitt

6
O, o zamana kadar kendini özdeş olarak çağırır, bitirmesini beklemeden, kendini tekrar çağırır: aka Fork Bomb
BCS

2
@Masi: Bilgisayar yeterince hızlıysa ve komut dosyası yeterince uzun değilse. Özel, eğer olacağını bilmiyorsanız.
voyager

3
Bırak #!/bin/bashve bence bu bash'taki en kısa forkbomb için bir golf kodunu kazanacak.
Joey Adams

11

Bir keresinde bir dizindeki dosyaları silmek istedim.

del *.*

Bilgisayar ardından "Emin misiniz? [Y / H]" dedi ben "! Sheesh aptal bilgisayarlar Emin, aksi takdirde ağ örme yazılı komutla olmazdı ediyorum DERSİN düşünce homur ..."

Y <enter>

C:\Windows>_

Um ... WTF? Windows dizinimi yeni mi sildim?

undelete *.*

Küçük sabit disklerin o günlerinde, c: \ windows'daki her bir dosyanın neye benzediğini ve adının ne olduğunu biliyordum, ancak her şeyi sildikten sonra bile sistem asla aynı değildi. "Emin misin" sorusuna biraz saygı duydum. Sadece biraz


1
Ben de bir kez aynısını yaptım. Yeniden başlatıp tekrar çalıştırmam gereken bir sistem var, ama bir daha asla doğru olmadı. Sistemi bir hafta sonra yeniden inşa ettim.
Jim OHalloran

11

Sanırım yaptığım en aptalca şey, dışa bakan güvenlik duvarı kümesindeki varsayılan rotayı kaldırmaktı; vpn ise yüzlerce mil öteden masaüstüme geldi.

Neyse ki, planlanan aksama süresi olarak belirlenmiş bir dönemdeydi (sadece durumda), ancak bu durum güvenlik duvarını yerinde gidip yeniden yapılandırmak için 200 mil turu kurtarmamı sağladı. Ayrıca seyahat sürem boyunca internete maruz kalan üretim sistemlerimizi ve sonrasında yapılan düzeltmeleri almamıza da yardımcı olmadı.

Hepimiz bir nano saniyenin tanımını biliyoruz. Bir saniye, daha da küçüktür ve “enter” a basmakla hatanızın farkına varmak arasındaki zamandır.


11

İkiden ilk ...

Bir Solaris kutusunda, AIX makinelerinin katran yedeklerini aldık.

Yazılan Geliştiricilerden biri:

tax xvf AIX_Backup.tar

Elbette vergideki yollar mutlaktı ve biz unix'in yeni bir dağıtımını yaptık ... Solarix ... Dağıtım ile ilgili tek sorun önyükleme yapmadığıdır :(


10

Hikaye bana anlattı:

Yerel PBX’in bazı sorunları olduğu için bir başka şube daha çağırdı. Bazı araştırmalardan sonra, sunucularını güncellediklerini, ancak Asterisk konfigürasyonlarının olmadığını öğrendik. Böylece, yönetici, şube görevlisine yapılandırmayı tekrar yapması talimatını vermeye karar verdi.

Yönetici: "Tamam, şimdi, rm -rf / etc / asterisk yazın"

Guy: "Tamam."

Yönetici: "Şimdi, cp / var / ..." yazın.

Guy: "Bekle, hala çalışıyor ..."

Yönetici: ??? ... !!!


1
Bir şey yanlış gidebilirse, yanlış gider.
Joey Adams

9
rm -rf / some/path 

yerine

rm -rf /some/path 

Neyse ki bana olmadı ;-)


son zamanlarda bir sınıf arkadaşıma oldu. Neyse ki sadece / etc / some / other / path ile yapıldı
Ikke

Devre dışı bırakılmalıdır! Şimdi birçok işletim sisteminde devre dışı olduğunu düşünüyorum. Denemek için çok korkmuş, Ubuntu rm -rf /
Lakshman Prasad

Aslında, sadece sudo rm -rf /
voyager

Orada yaptım, yaptım ...
fgysin, Monica



8

XCOPYgüçlü bir canavardır - idamında acımasızdır ve komut satırının argümanlarının Window'lardan COPYve UNIX'lerden tersine gitmesi geriliği nedeniyle geciktirir cp.

Birkaç gün önce yanlışlıkla şöyle yazdım:

xcopy src \path\to\a\new\nonexistent\directory

XCOPYdizimi üzerine yazacak kadar kibardı src... hiçbir şey! Eski dosyaları Geri Dönüşüm Kutusu'na koymak da zahmete girmedi.

Oh, ve XCOPYaslında yeni olanları tahsis etmek yerine diskteki aynı sektörlerin üzerine yazdığı ortaya çıktı . 3 disk kurtarma programı denedim ve en iyisi kaybedilen 10 dosyanın sadece 3'ünü kurtarabilirdi. Tabii ki bu 3 dosya sadece vshost.exeve arkadaşlarıydı. Kabarma!


8

ağda sorun yaşandı (uzaktaki bir makinede) ve arayüzü yeniden başlatmak istedim

ifconfig eth0 down && ifconfig eth0 upp

Günümüzde, böyle şeyleri denemeden önce birinin makineye yakın olduğundan emin olun (iptables da iyi bir adaydır). Kimse yokken, bir kere yazdım

sleep 600; reboot

başka bir (ekran) terminaline, böylece 10 dakika içinde komutu ctrl + c yapamazsam yeniden başlatacaktı.

Ben de bu hatayı öğrendim (ctrl + c, uyku yeniden başlatılacak) ve şimdi kullanıyorum

sleep 600 && reboot

bu da ctrl + c ile çalışmamı sağlayacak.


1
shutdown -r +5Örneğin shutdownişlemi durdurmazsanız sistemi 5 dakika içinde yeniden başlatır killall shutdown.
gelraen

1
Solari'nin altında Mihi'nin hatasını yapan yöneticiyi görebiliyorum, sonra (hatadan ders alarak) gelraen'in alternatifini deniyor.
outis

8
ifconfig eth0 down

Üzgünüz, eth0’un dış tarafındayım. Web sunucusu dünyanın öbür tarafında, kilitli bir odada. Oturum açmak veya yeniden başlatmak için ağ erişimi yok. Bok.


6

Tüm gizli dosyaları ve dizinleri bu şekilde kaldırmaya çalışırken neden aptal olduğumu söyleyebilen herkese bedava bir çerez:

rm -rf. *


1
Komutunuz, geçerli dizininizin altındaki alt dizinleri de kaldırıyor mu?
Léo Léopold Hertz 준영

Ben senin desen eşleştirme eğer merak ..hardlink
Mircea Vutcovici

BTW, ikiniz de kurabiyeleri kazandınız :-)
Matt Simmons

6

Bir üretim web sunucusundaki ana klasörümü temizlerken, sunucunun web kökünü ana klasörümdeki bir yere bağladığımı unuttum. Düşünmüyorum, bu klasörde bir rm-rf koştum ve bildiğim bir sonraki şey, insanlar web sitesinin kapalı olduğunu söylüyorlar!

Oops!


5

Bir keresinde iki klasördeki verileri karşılaştırıyordum ve -d seçeneğiyle rsync kullandım (kaynaktaki hedef üzerindeki dosyaları sil). Ve sonra rsync'i çalıştırdığımda kaynak ve hedef arasında geçiş yaptım. Yedeklemek istediğim tüm yeni dosyaları sildi. Şimdi -n (dry-run) ile rsync çalıştırmayı öğrendim.

rsync -trvd --stats --progress /destination /source

Desteğim yoktu.


4

Bir zamanlar (muhtemelen Sistem III, ancak uzun zaman önceydi), *doğru kabuk alıntı kullanarak bir dosya oluşturmak mümkündü . Birini ev dizinimde bulduğumda, bir rm *şey tereddüt ettiğinde ve düşünürken ...

Diğer kullanıcılar için böyle bir dosya oluşturmak ortak bir şakaydı.

Dosya bir dizinde oturuyorsa, hafifletilmesi zor bir dosyadır. Adını tam olarak lsgöründüğü gibi yazacak olan refleks oldukça güçlü.

Diğer (daha az zararlı) şakası, kaldırılması çok daha zor olan beyaz alandan (veya sadece beyaz alandan) takip eden dosyaları adlandırmak ...


2
GUI'ler bunun içindir :)
Zifre

1
Kabuk tamamlama, bu boşluk dosyaları için gerçek bir zaman tasarrufu sağlar :)
Bay Shiny ve Yeni 安 宇

1
Bu ca. 1985 ve çevirmeli bağlantı yoluyla veya bir VT-100 terminalinin bir klonundan gelen bir RS-232 kablosu ile erişildi. Bir terminal emülatörü değil, gerçek bir terminal. O zaman isim tamamlamayı csh hatırlamıyorum ... ;-) Bugün, elbette, GUI'ler ve isim tamamlama bu ikisini de daha az riskli hale getiriyor ve birçok işletim sistemi başvurmadan bu tür dosyaları oluşturmayı çok zorlaştırıyor disk sektörü düzenleme ....
RBerteig

rm --help ne de rm * çalışacak ... ne o zaman ./--help dokunun
mihi

Yine de , en azından Linux'ta bir dosya oluşturabilirsiniz : "dokunma ". Ve "rm '*'" de çalışır ...
sleske

4

Yeniden başlatma sonrası genel JBoss lapa lapa laflığı konusundaki bazı kötü deneyimler nedeniyle, yeniden başlatılmadan önce JBoss'un çalışma dosyalarını silmeyi seviyorum. Normalde yapardım:

# cd /var/cache/jboss
# rm -rf tmp/* work/*

Kendimi olası felaket hatalarından herhangi birini yazmaya karşı korumak için:

  • / Tmp / *
  • tmp / *
  • kaptın bu işi

Son komutu ben yaparım:

# sudo -u jboss rm -rf tmp/* work/*

JBoss kullanıcısı, kendisine ait olmayan kritik dosyaları çıkarmakta zorlanır.

Asla bu hatayı yapmadım, ama yaptığım durumda güvende olurum.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.