Jak „hibernować” proces w Linuksie, przechowując jego pamięć na dysku i przywracając go później?

Czy można „hibernować” proces w systemie Linux? Podobnie jak w przypadku „hibernacji” w laptopie, zapisałbym całą pamięć używaną przez proces na dysk, zwolniłbym pamięć RAM. Później mogę „wznowić proces”, tj. Odczytać wszystkie dane z pamięci i umieścić je z powrotem w pamięci RAM i kontynuować proces?

Utrzymywałem CryoPID , program, który robi dokładnie to, o czym mówisz. Zapisuje zawartość przestrzeni adresowej programu, VDSO, odniesienia do deskryptorów plików i stany do pliku, który można później zrekonstruować. CryoPID rozpoczął się, gdy w samym Linuksie nie było użytecznych haków i działał całkowicie z przestrzeni użytkownika (w rzeczywistości nadal działa, w zależności od ustawień dystrybucji / jądra / zabezpieczeń).

Problemami były (rzeczywiście) gniazda, oczekujące sygnały RT, liczne problemy z X11, implementacja getpid () buforowania glibc i wiele innych. Randomizacja (zwłaszcza VDSO) okazała się nie do pokonania dla nielicznych z nas pracujących nad nią po odejściu Bernarda. Było jednak fajnie i stało się tematem kilku prac magisterskich.

Jeśli zastanawiasz się tylko nad programem, który może zapisać swój stan pracy i ponownie uruchomić go bezpośrednio do tego stanu, to znacznie ... znacznie ... łatwiej jest po prostu zapisać te informacje z samego programu, na przykład podczas obsługi sygnału.

Chciałbym zamieścić tutaj aktualizację statusu od 2014 roku.

Przyjęta odpowiedź sugeruje CryoPID jako narzędzie do wykonywania Checkpoint / Restore, ale okazało się, że projekt nie jest utrzymywany i niemożliwy do skompilowania z najnowszymi jądrami. Teraz znalazłem dwa aktywnie utrzymywane projekty zapewniające funkcję punktów kontrolnych aplikacji.

Pierwszym, który sugeruję, bo mam więcej szczęścia podczas jego uruchamiania, jest CRIU, który wykonuje punkty kontrolne / przywracanie głównie w przestrzeni użytkownika i wymaga włączonej opcji jądra CONFIG_CHECKPOINT_RESTORE.

Punkt kontrolny / Przywróć w przestrzeni użytkownika lub CRIU (wymawiane kree-oo, IPA: / krɪʊ /, rosyjski: криу) to narzędzie programowe dla systemu operacyjnego Linux. Za pomocą tego narzędzia możesz zamrozić uruchomioną aplikację (lub jej część) i przenieść ją na dysk twardy jako zbiór plików. Następnie możesz użyć plików do przywrócenia i uruchomienia aplikacji od momentu, w którym została zablokowana. Charakterystyczną cechą projektu CRIU jest to, że jest on realizowany głównie w przestrzeni użytkownika.

Ten ostatni to DMTCP ; cytując z ich strony głównej:

DMTCP (Distributed MultiThreaded Checkpointing) to narzędzie do przejrzystego sprawdzania stanu wielu jednoczesnych aplikacji, w tym aplikacji wielowątkowych i rozproszonych. Działa bezpośrednio na pliku wykonywalnym użytkownika, bez żadnych modułów jądra Linuksa lub innych modyfikacji jądra.

Jest też fajna strona Wikipedii dotycząca argumentu: Application_checkpointing

Wspomniane odpowiedzi ctrl-ztak naprawdę mówią o zatrzymaniu procesu sygnałem, w tym przypadku SIGTSTP. Możesz wysłać sygnał stopu za pomocą kill:

kill -STOP <pid>

Spowoduje to zawieszenie wykonywania procesu. Nie spowoduje to natychmiastowego zwolnienia używanej przez niego pamięci, ale ponieważ pamięć jest wymagana dla innych procesów, pamięć używana przez zatrzymany proces będzie stopniowo wymieniana.

Jeśli chcesz go ponownie obudzić, użyj

kill -CONT <pid>

Bardziej skomplikowane rozwiązania, takie jak CryoPID, są naprawdę potrzebne tylko wtedy, gdy chcesz, aby zatrzymany proces mógł przetrwać zamknięcie / ponowne uruchomienie systemu - nie wydaje się, że tego potrzebujesz.

Problemem jest przywrócenie strumieni - plików i gniazd - które program otworzył.

Gdy cały system operacyjny przechodzi w stan hibernacji, pliki lokalne i tym podobne można oczywiście przywrócić. Połączenia sieciowe nie, ale wtedy kod, który uzyskuje dostęp do Internetu, jest zwykle bardziej sprawdzany pod kątem błędów i tym podobnych, i przetrzymuje warunki błędu (lub powinien).

Jeśli wykonałeś hibernację dla poszczególnych programów (bez obsługi aplikacji), jak poradzisz sobie z otwartymi plikami? Co się stanie, jeśli inny proces uzyska dostęp do tych plików w międzyczasie? itp?

Utrzymanie stanu, gdy program nie jest załadowany, będzie trudne.

Zwykłe zawieszenie wątków i umożliwienie ich zamiany na dysk miałoby podobny efekt?

Lub uruchom program na maszynie wirtualnej i pozwól maszynie wirtualnej obsłużyć zawieszenie.

Linux Kernel częściowo zaimplementował futures punktu kontrolnego / restartu: https://ckpt.wiki.kernel.org/ , stan jest tutaj .

Kilka przydatnych informacji można znaleźć w lwn (cotygodniowa sieć linuxa): http://lwn.net/Articles/375855/ http://lwn.net/Articles/412749/ ......

Więc odpowiedź brzmi „TAK”

Krótka odpowiedź brzmi „tak, ale nie zawsze rzetelnie”. Sprawdź CryoPID:

http://cryopid.berlios.de/

Otwarte pliki będą rzeczywiście najczęstszym problemem. CryoPID wyraźnie stwierdza:

Otwarte pliki i przesunięcia są przywracane. Pliki tymczasowe, które zostały odłączone i nie są dostępne w systemie plików, są zawsze zapisywane w obrazie. Inne pliki, które nie istnieją przy wznowieniu, nie są jeszcze przywracane. Planowana jest obsługa zapisywania zawartości plików w takich sytuacjach.

Te same problemy wpłyną również na połączenia TCP, chociaż CryoPID obsługuje tcpcp do wznawiania połączenia.

Krótka odpowiedź brzmi „tak”. Możesz zacząć od spojrzenia na to, aby znaleźć kilka pomysłów: rekonstrukcja pliku wykonywalnego ELF z obrazu podstawowego ( http://vx.netlux.org/lib/vsc03.html )

Rozszerzyłem Cryopid o pakiet o nazwie Cryopid2 dostępny na SourceForge. Może to migrować proces, a także hibernować go (wraz z wszystkimi otwartymi plikami i gniazdami - dane w gniazdach / potokach są zasysane do procesu podczas hibernacji i wypluwane z powrotem do nich po ponownym uruchomieniu procesu).

Powodem, dla którego nie byłem aktywny w tym projekcie, jest to, że nie jestem programistą jądra - zarówno ten (i / lub oryginalny kriopid) musi mieć na pokładzie kogoś, kto może uruchomić je z najnowszymi jądrami (np. Linux 3.x) .

Metoda Cryopid działa - i jest prawdopodobnie najlepszym rozwiązaniem do hibernacji / migracji procesów ogólnego przeznaczenia w systemie Linux, z jakim się spotkałem.

Jak zauważyli inni, systemowi operacyjnemu trudno jest zapewnić tę funkcjonalność, ponieważ aplikacja musi mieć wbudowane funkcje sprawdzania błędów w celu obsługi uszkodzonych strumieni.

Jednak na marginesie, niektóre języki programowania i narzędzia, które używają maszyn wirtualnych, wyraźnie obsługują tę funkcję, na przykład język programowania Self .

Ctrl-Z zwiększa szanse na zamianę stron procesu, ale nie zwalnia całkowicie zasobów procesu. Problem z całkowitym zwolnieniem zasobów procesu polega na tym, że takie rzeczy jak uchwyty plików, gniazda są zasobami jądra, z których proces może korzystać, ale nie wie, jak przetrwać samodzielnie. Więc Ctrl-Z jest tak dobre, jak to tylko możliwe.

Przeprowadzono pewne badania dotyczące punktu kontrolnego / przywracania Linuksa w ciągu 2.2 i 2.4 dnia, ale nigdy nie wyszło to poza prototyp. Jest to możliwe (z zastrzeżeniami opisanymi w innych odpowiedziach) dla pewnych wartości możliwych - ja możesz napisać moduł jądra, aby to zrobić, jest to możliwe. Ale dla wspólnej wartości możliwej (czy mogę to zrobić z powłoki na komercyjnej dystrybucji Linuksa), nie jest to jeszcze możliwe.

To jest jakby ostateczny cel klastrowego systemu operacyjnego. Mathew Dillon wkłada wiele wysiłku, aby zaimplementować coś takiego w swoim projekcie Dragonfly BSD .

dodanie kolejnego obejścia: możesz użyć virtualbox. uruchamiaj aplikacje na zwykłej maszynie wirtualnej i po prostu „zapisz stan maszyny”, kiedy tylko chcesz. Wiem, że to nie jest odpowiedź, ale pomyślałem, że może się przydać, gdy nie ma prawdziwych opcji.

jeśli z jakiegoś powodu nie lubisz virtualbox, vmware i Qemu są równie dobre.

Jest ctrl+zw systemie Linux, ale nie jestem pewien, czy oferuje określone funkcje. Podejrzewam, że zadałeś to pytanie, ponieważ tak nie jest