Sed çıkışını aynı giriş dosyasına yönlendirmek neden makinemi yanıt vermiyor?

sedBüyük bir dosyada (100 MB) bazı anahtar kelimeleri değiştirmeye çalışıyordum . Ben -i(inplace) seçeneğinin farkında değildi , bu yüzden ilk denemem bu şekilde yönlendirme oldu:

sed 's/original/edited/g' file.log >> file.log

bundan sonra olan şey, bilgisayarımın neredeyse hiç klavye girişi olmaması için durmasıydı. Farklı bir konsol Ctrl+ Alt+ denedim F1ancak yavaş yavaş kullanıcı adını girdikten sonra da durdu. Klavye olmadan tek seçeneğim makineyi donanımdan sıfırlamaktı. Giriş yaptıktan sonra file.log dosyasının yaklaşık 8 GB olduğunu gördüm.

Bu komutun yürütülmesinin sistemi neden bu kadar tepkisiz hale getirebildiğini ve uyarıları tetikleyen ve rahatsız edici işlemi öldüren sistem düzeyinde mekanizmalar olup olmadığını gerçekten anlamak istiyorum?

command-line sed

— cesarpachon
kaynak

Bu tek çekirdekli bir makine mi? Bunun modern bir bilgisayarı dizlerinin üstüne getirmesi çok garip görünüyor. Diskinizi doldurun, evet. Çekirdeklerinden birinin% 100'ünü tüketti, evet. Ama tam bir kaza mı?

— terdon

Bu dosya hakkında tuhaf bir şey var mı? bu bir sorun değilse, içeriğini pastebin'e gönderebilir misiniz?

— Sergiy Kolodyazhnyy

Ayrıca, hafızanızın miktarı nedir? Bize çıktı verebilir misiniz free -h ?

— Sergiy Kolodyazhnyy

Bir dosyayı değiştirmek istediğinizde neden ilk sırada bir akış düzenleyici kullanıyorsunuz? yan etkileri ex -sc '%s/original/edited/ge|x' file.logolmadan UNIX deyimiyle istediğinizi yapmalısınız sed -i.

— David Ongaro

Doğru bir şekilde yapsanız bile (insanların sağladığı yöntemlerden herhangi biri ile), etkin bir sürece ait bir günlük dosyasına bu tür bir şey yapmak zor olabilir.

— Random832

Yanıtlar:

Daha önce de belirtildiği gibi, >>dosyaya eklenir, böylece sedkomutunuz orada çıkardığı satırları okuyarak ve daha sonra çıktısını verir. Eğer yerinde dosyanızı değiştirmek istiyorsa >hala iş olmaz, ancak bir konum farkında sedbireyin -ikesinlikle istediğiniz biridir seçenek.

Bununla birlikte, okuduğunuz bir dosyaya akış olarak eklemek istediğinizden ve bunun yalnızca bir geçişini yapmak istediğinizden kesinlikle eminseniz sponge, moreutilspaketten kullanmayı düşünün ;

sed 's/original/edited/g' file.log | sponge >> file.log

spongeEOF'a kadar stdin'den belleğe okur, daha sonra tüm içeriğini stdout'a döker, bu nedenle seddosyanın sonuna vurur, okumayı durdurur, kapatır ve sonra sünger eklenmeye başlar.

— ymbirtt
kaynak

spongehakkında bilmek güzel aracıdır ama sedzaten vardır -iseçeneği: -i[SUFFIX], --in-place[=SUFFIX], edit files in place (makes backup if SUFFIX supplied).

— Joshua Taylor

@JoshuaTaylor, OP >>yerine >onun yerine ekleyen kullanıyordu . Verilen, OP özellikle -ipostada özellikle bahsetmişti ve bundan çok daha yaygın bir kullanım durumu gibi görünüyor, ancak OP'nin yayınladığı belirli işlemin çok fazla faff olmadan mümkün olduğunu belirtmeye değer olduğunu düşündüm, eğer gerçekten emin olmak istediğiniz şey bu.

— ymbirtt

Burada bahsettim çünkü kabul edilen cevabın anahtarı buydu . Yani dedim ben öğrenmek için gerçekten mutlu sünger ; araç kutum için yeni bir araç ve sadece bunun için bir upvote'a layık.

— Joshua Taylor

Ah! Anlıyorum. Bunu biraz daha net hale getirmek için cevabımı değiştireceğim. Ayrıca, eğer zevk sponge, bir göz atın vipe. moreutilssadece ihtiyacınız olmadığını bilmediğiniz şeylerle dolu büyülü bir paket

— ymbirtt

Sizin sedkomut o eklemeden edildi dosyayı okumaya çalışıyordum. Asla Dosya Sonu'na ulaşmayacak, ancak çalışırken çok fazla CPU zamanı yiyecektir. Bu yüzden ^ C (kesinti süreci) icat edildi.

— waltinator
kaynak

Ben ^ C orada bir seçenek olduğunu sanmıyorum ... bir HALT gitti, yani yanıp sönen hiçbir imleç, sıkışmış!

— EKons

Okuduğunuz dosyaya geri eklemek hiçbir zaman iyi bir fikir değildir, çünkü sürekli büyüyen bir dosyaya sahip olursunuz. Dosyaya gerçekten yazmak istiyorsanız -ibayrağı kullanmalısınız :

sed -i 's/original/edited/g' file.log

veya değişiklik yapmadan önce yedek oluşturmasını istiyorsanız -ibayrağa bir dosya soneki ekleyebilirsiniz :

sed -i.bak 's/original/edited/g' file.log

Bu, adlandırılan file.log.bakve daha sonra değişiklikler yaparak, okuduğunuz dosyaya eklemeye çalışarak orada ne yaptığınızı yaratacaktır. . Bu yüzden makineniz de durdu.

— Videonauth
kaynak

Bunun kabul edilen cevap olduğuna şaşırdım, çünkü OP'nin sorusuna bile

"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

@Steve Neden bir durma noktasına geldiğini söyledim, ama ikinci kısım için haklısın. Buna değinmedim çünkü buna bir cevap bilmiyorum. Bir sohbet tartışmasından sonra komutu kapsamlı bir şekilde test ettik ve farklı makinelerde ve işletim sistemlerinde tamamen farklı sonuçlar elde ettik. Örnek: Kemerli bir makinede yalnızca dosyanın sonsuza kadar büyümesine izin verir, ancak makineyi yanıt vermiyor hale getirir. Ubuntu makinemde, sorguyu yapan kişiyle aynı sonucu elde etme şansım yoktu. Aynı şeyi bir Ubuntu VM'sinde test eden ikinci bir makine aynı durma noktasına geldi.

— Videonauth

Bir stracediğer tarafı didtn üzerinde tüm sürecin benim makinede ve diğer kullanıcı makinedeki sonucunu ve bu ürer. Yanıt vermeyen uygulamaları öldürebileceğiniz bir mekanizma olduğundan emin olun, ancak makineniz yanıt vermiyorsa, tek bir seçeneğiniz kaldı ve sıfırlayın. Bu konuda hala test yapıyorum ve açıklanan davranışa neyin neden olduğunu tam olarak anlamadan önce, sorunun bu kısmını ele alamıyorum.

— Videonauth

Muhtemelen çekirdek konfigürasyonlarında, G / Ç'ye öncelik veren farklı bir zamanlayıcı veya sistemler arasındaki disk / dosya sistemi sürücüsündeki farklılıklar gibi bir fark vardır. Yaptığınız soruşturmayı görmek güzel, bu iyi bir bilgi.

— Steve

Başka bir veri noktasıyla ilgileniyorsanız; Bunu oldukça küçük bir dosyaya sahip bir CentOS makinesinde denedim ve aşağıdaki sünger çözümümle tamamen aynı şeyi yaptı. Küçük bir dosya sediçin tutamacı tutmak yerine her şeyi belleğe arabelleğe alıp kapatacağını hayal ediyorum . OP'de olduğu gibi ~ 100MB'lık bir dosya ile süresiz olarak büyüdü, ancak makineyi tuğlalamadı.

— ymbirtt