Page 110 of 165

Błąd “Errno::EMFILE: Too many open files” w testach jednostkowych

Dzisiaj pisząc kolejną porcję testów do Senpuu v5, po odpaleniu ich pod RCovem i Rubym 1.8.7 napotkałem na taki oto błąd:

Errno::EMFILE: Too many open files

Błąd ten związany jest z ilością otwartych jednocześnie plików (co ciekawe nie wystąpił podczas odpalania testów pod 1.9.2). Okazuje się, że tego typu wywołania:

file = File.new(File.join(Rails.root, "sciezka/do/pliku"), 'rb')

nie są nigdy zamykane, więc otwierając przykładowo 100 plików, żaden z nich nigdy nie zostanie zamknięty (przy zamykaniu aplikacji zostana). Z czasem ilość otwartych plików narasta i po pewnym czasie następuje zgłoszenie wyżej wspomnianego wyjątku. Rozwiązanie jest nader proste: zamykajmy otwierane pliki :)

W przypadku aplikacji jest to dość proste (robimy coś na pliku, kończymy i zamykamy). Jak jednak zapanować nad otwartymi plikami w testach? Przyznam szczerze, że jestem zbyt dużym leniem aby pamiętać o zamykaniu każdego pliku otworzonego w każdym teście. Z tego względu warto zbudować sobie prosty garbage collector który zajmie się tym za nas. Jak to zrobić pokaże na przykładzie podpięcia takiego kodu pod ActiveSupport::TestCase. Nic nie stoi na przeszkodzie aby tę metodę stosować także dla innych frameworków jak np. RSpec.

W metodze setup deklarujemy zmienną instancyjną, która przechowywać będzie nasze otwarte pliki:

  def setup
    super
    # Jakis inny kod ...
    @opened_files = []
  end

W metodzie teardown zamykamy wszystko:

  def teardown
    super
    # Jakis inny kod
    @opened_files.each { |f| f.close }
  end

I ostatnia z metod - metoda otwierająca pliki i zapamiętująca je w naszej zmiennej:

  def open_file(file = nil)
    return nil if filename.nil?
    file = File.new(File.join(Rails.root, file), 'rb')
    @opened_files << file
    file
  end

Od teraz, korzystając z metody open_file nie musimy się martwić otwartymi plikami. Zostaną automatycznie zamknięte podczas wywołania metody teardown.

Ubuntu i “No init found. Try passing init= bootarg”

Nieprawidłowe wyłączanie komputera może być dość dramatyczne w skutkach. Część z was wie, że jestem właścicielem małego serwera (który tak naprawdę jest zwykłym komputerem ;) ), na którym wykonuję testy aplikacji oraz stawiam wersje developerskie (alfy, bety, itd). Oczywiście robię mu regularne backupy, jednak sami dobrze wiecie, że "pad" jakiegokolwiek komputera to po prostu masa pracy z postawieniem go na nowo. W przypadku serwerka dochodzi konfiguracja na nowo, itd.

Wczoraj w skutek nagłego spadku zasilania - zresetował mi się wspomniany wyżej serwer i niestety... już nie wstał. Dostawałem za to piękną wiadomość:

mount: mounting /dev/disk/uuid/***************************** on /root
failed: Invalid argument
mount: mounting /sys on /root/sys failed: No such file or directory
mount: mounting /dev on /root/dev failed: No such file or directory
mount: mounting /sys on /root/sys failed: No such file or directory
mount: mounting /proc on /root/proc failed: No such file or directory
Target file system doesn't have /sbin/init
No init found. Try passing init= bootarg

Busybox v1.13.3 (Ubuntu 1:1.13.3-1ubuntu7) built-in shell (ash)
Enter 'help' for a list of built-in commands
(initramfs) _

Co się stało? Po prostu "padła" jedna z partycji. Naprawa tego typu problemów nie jest trudna (o ile wysypała się partycja a nie np. padł dysk). Musimy mieć bootowalną wersję Linuksa (na pendrivie lub na płycie CD). Odpalamy takie Live CD a następnie przechodzimy do terminala. Wpisujemy komendę:

sudo fdisk -l 

aby dowiedzieć się jakie partycje mamy na dysku i mamy (przykładowo):

Dysk /dev/sda: 80.0 GB, bajtów: 80026361856
głowic: 255, sektorów/ścieżkę: 63, cylindrów: 9729
Jednostka = cylindrów, czyli 16065 * 512 = 8225280 bajtów
Rozmiar sektora (logiczny/fizyczny) w bajtach: 512 / 512
Rozmiar we/wy (minimalny/optymalny) w bajtach: 512 / 512
Identyfikator dysku: 0x85f285f2

Urządzenie Rozruch   Początek      Koniec   Bloków   ID  System
/dev/sda1               1         125     1004031   82  Linux swap
/dev/sda2   *         126        1993    14999552   83  Linux
/dev/sda3            1993        3860    14999552   83  Linux
/dev/sda4            3860        9730    47145985    5  Rozszerzona
/dev/sda5            3860        5728    14998528   83  Linux
/dev/sda6            5728        9730    32146432   83  Linux

Następnie uruchamiamy program fsck na każdej z partycji (tak dla pewności), wykonując następujące polecenie:

# Zmieniamy kolejno na #sda1, sda2, sda3, itd
sudo fsck /dev/sda2

Po tym zabiegu restartujemy serwer i cieszymy się działającym systemem. Następnie zamawiamy UPSa aby taka sytuacja więcej się nie zdarzyła.

Dla pewności, możemy wymusić autouruchomienie fsck przy starcie systemu, wpisując:

sudo touch /forcefsck

Utworzoenie pliku forcefsck w głównym katalogu - spowoduje, że system wstając wykryje go i wykona jeszcze raz testy na partycjach. Po tych operacjach wszystko powinno wrócić do normy.

Copyright © 2024 Closer to Code

Theme by Anders NorenUp ↑