Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Выпуск CRIU 4.2, системы для сохранения и восстановления состояния процессов в Linux"	+/–
Сообщение от opennews (??), 14-Ноя-25, 09:28
После шести месяцев разработки опубликован выпуск инструментария CRIU 4.2 (Checkpoint and Restore In Userspace), предназначенного для сохранения и восстановления процессов в пространстве пользователя. Инструментарий позволяет сохранить состояние одного или группы процессов, а затем возобновить работу с сохранённой позиции, в том числе после перезагрузки системы или на другом сервере без разрыва уже установленных сетевых соединений.  Код проекта написан на языке Си и распространяется под лицензией GPLv2. CRIU применяется в таких системах управления контейнерами, как OpenVZ, LXC/LXD и Docker. Необходимые для работы CRIU изменения включены в основной состав ядра Linux... Подробнее: https://www.opennet.me/opennews/art.shtml?num=64248
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по ответам | RSS]

1. Сообщение от Аноним (1), 14-Ноя-25, 09:28	+2 +/–
Использую в продуктивной системе, здоровья проекту!
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #10

2. Сообщение от Жироватт (ok), 14-Ноя-25, 09:50	+/–
Попробовал. Хм...Джава-стек сумело корректно сохранить и восстановить
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #3

3. Сообщение от Аноним (3), 14-Ноя-25, 09:54	–1 +/–
А чего там восстанавливать? Только с видеокартами были сложности. Лучше расскажи, какое практическое применение есть? Я могу придумать только продолжительный рендер без возможности прервать и срочное обновление.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #7, #30, #32, #33

4. Сообщение от Шарп (ok), 14-Ноя-25, 09:54	–2 +/–
>без разрыва уже установленных сетевых соединений Это невозможно. Другая сторона в сетевом соединении увидит разрыв. Если есть данные прикреплённые к сессии, то они сбросятся.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #6, #9, #31

5. Сообщение от trolleybus (?), 14-Ноя-25, 09:59	–4 +/–
> Устранено целочисленное переполнение в функции pagemap_len() А вот это типично сишная проблема. Многие тупо не парятся и везде пишут int, когда даже стандартом не определено, сколько точно байтофф оно занимает, ибо architecture dependent. Про знаковые/беззнаковые вообще молчу. А использовать всякие uint32_t не хотим, это ненужное ненужно. Даже в расте такой номер не пройдет, если только специально не поиздеваться.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #8, #11, #20

6. Сообщение от Аноним (3), 14-Ноя-25, 10:18	+1 +/–
Другая сторона только отвалится по таймауту. Если не успеет, то всё будет как будто у нас тут небольшой свопинг приключился.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4

7. Сообщение от Жироватт (ok), 14-Ноя-25, 10:29	+/–
На старых версия не всегда корректно работал с большим количеством JNI-вызовов, ведь должны захватываться и они. > Лучше расскажи, какое практическое применение есть? Рендер, расчеты. На билдферме может выполняться сборочный процесс. Иногда просто нежелательно тушить процесс
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #16

8. Сообщение от Пыщь (?), 14-Ноя-25, 10:32	+3 +/–
Понравилась цитата защищавшего расто-операторов, суну сюда: "Это вы себе что-то придумывете. А люди обучаются, исправляют ошибки, получают знания и удовольствие."
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #21

9. Сообщение от Аноним (9), 14-Ноя-25, 10:33	+1 +/–
Там специальные подпорки в ядре, позволяющие реконструировать внутреннее состояние сокета без использования вызовов сокетного апи, поэтому сокет будет восстановлен точно в том же состоянии, и если удалённая сторона не затаймаутилась - то она ничего не заметит, закрытия сокета и посылки FIN не происходит, а после разморозки трафик едет дальше, как ни в чём не бывало.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #13

10. Сообщение от привет (ok), 14-Ноя-25, 10:57	+/–
продуктовой (с) тех-лид ВТБ
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #17

11. Сообщение от Медведь (ok), 14-Ноя-25, 11:43	–2 +/–
> А вот это типично сишная проблема. Бред сивой кобылы. Такое возможно в любом  ЯП, где целые занимают фиксированный размер в памяти. Ржа тоже вполне себе подвержена ошибкам из-за выхода за допустимый диапазон значений. Забавно, ржавозависимые при каждом баге в растокоде упрекают всех, что от их драгоценной ржи требуют чего-то, чего ржа не обещала, но сами не могут определиться с тем, чего же она все-таки обещала ;)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #14

12. Сообщение от Catwoolfii (ok), 14-Ноя-25, 12:00	+1 +/–
эту штуку могли бы использовать в proxmox для живой миграции контейнеров lxc
Ответить | Правка | Наверх | Cообщить модератору

13. Сообщение от Аноним (13), 14-Ноя-25, 12:16	+1 +/–
> после разморозки трафик едет дальше, как ни в чём не бывало. даже через неделю?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9 Ответы: #15, #25

14. Сообщение от morphe (?), 14-Ноя-25, 12:21	+1 +/–
Ржавчина использует для подобных вещей везде isize/usize, и не позволяет неявных конверсий между ним и int В то время как в сишке для совместимости везде int и грабли
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #18

15. Сообщение от Аноним (16), 14-Ноя-25, 12:28	+/–
Через неделю-то тайаут произойдёт. Но если только та сторона тоже решила заморозиться, то и через месяц.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13

16. Сообщение от Аноним (16), 14-Ноя-25, 12:30	–1 +/–
Сборка Раста.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7

17. Сообщение от Аноним (17), 14-Ноя-25, 13:17	+1 +/–
В проде (с) тех-лид Сбера
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #27

18. Сообщение от Медведь (ok), 14-Ноя-25, 13:25	–1 +/–
И теперь usize::MAX + 1 не приведет к переполнению, да-да-да. Вот откуда вы лезете?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14 Ответы: #22, #23

19. Сообщение от Аноним (19), 14-Ноя-25, 14:52	+1 +/–
Когда сделают live миграцию LXC контейнеров в Proxmox VE как это было ранее когда были OpenVZ контейнеры?
Ответить | Правка | Наверх | Cообщить модератору

20. Сообщение от Медведь (ok), 14-Ноя-25, 15:15	+/–
> стандартом не определено, сколько точно байтофф оно занимает, ибо architecture dependent В рже, внезапно, размер usize и isize тоже зависит от архитектуры. Сюрприз!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #24

21. Сообщение от Аноним (16), 14-Ноя-25, 15:25	+/–
Удовольствие от сношения с боровом? У борова актиная позиция.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8

22. Сообщение от morphe (?), 14-Ноя-25, 15:40	+1 +/–
> И теперь usize::MAX + 1 не приведет к переполнению, да-да-да. Вот откуда > вы лезете? Если что-то может переполниться, в Rust можно явно это обрабатывать через checked_add/saturating_add/strict_add/wrapping_add/overflowing_add, а не делать проверки вида a + b < a и надеяться что компилятор тут поймёт что это проверка на переполнение, а не UB (Потому что по стандарту это UB)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #28

23. Сообщение от trolleybus (?), 14-Ноя-25, 15:53	+/–
> И теперь usize::MAX + 1 не приведет к переполнению, да-да-да Штука в том, что в расте тоже можно много чего натворить, но только если ты этого очень сильно захочешь. А в сишке ты можешь натворить, даже если очень не хочешь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18

24. Сообщение от trolleybus (?), 14-Ноя-25, 16:00	+/–
Так это и документировано. На 32 битах - 32 бита, на 64 - 64. И никаких сюрпризофф. А в сишке внезапно в одной и той же архитектуре может в разных ABI отличаться (например, размер лонга на линуксе 64 бита, на винде 32).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20 Ответы: #26

25. Сообщение от Аноним (25), 14-Ноя-25, 18:50	+1 +/–
Хоть через год, если настроишь тайм-ауты на обеих сторонах. Компьютеру без разницы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13

26. Сообщение от Аноним (3), 14-Ноя-25, 19:21	+/–
Это пока майкрософт и прочие не написали свой компилятор раста для 128 битных процессоров. Ну хотя у раста нет ABI, думать об этом и не придётся.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24

27. Сообщение от Xenia Joness (ok), 14-Ноя-25, 19:43	–1 +/–
> продуктовой (с) тех-лид ВТБ > В проде (с) тех-лид Сбера Продолжу дальше: В проде (с) тех лид Гугла В проде (с) тех лид Мелкософта В проде (с) тех лид НАСА В проде (с) тех лид "Рога и копыта"
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17

28. Сообщение от _ (??), 14-Ноя-25, 22:12	–1 +/–
> Если что-то может переполниться, в Rust можно явно это обрабатывать через checked_add/saturating_add/strict_add/wrapping_add/overflowing_add, Ыыыы :) А такое-же в Си сделать по твоему - технически не возможно, да? ;)))))))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22

29. Сообщение от Аноним (29), 15-Ноя-25, 00:26	+/–
Просто criu писали виртуоззники, у них под миграцию контейнеров между хостами все было заточено, так как виртуозза для хостеров и их shamand автоматом мигрировал контейнеры с проблемных хостов. В комплекте с виртуоззо сторадж это была довольно удобная вещь. Проксмокс скорее про небольшие внедрения, и фича эта была в нем просто из комплекта от openvz, чего видимо в lxc не доделали, потому что похоже коммерческого интереса хостить на lxc клиентов особо нет. Виртуозза к сожалению помирает, 7 версия была ох как давно, а 9я нововыпущенная - это совсем другой продукт, и даже без контейнеров вовсе. Но с другой стороны щас всем куб подавай.
Ответить | Правка | Наверх | Cообщить модератору

30. Сообщение от Lamerok (?), 15-Ноя-25, 03:24	+/–
ты же тот самый техлид выше? и не знаешь применения для этой технологии?! ну тогда я рассказывать точно небуду)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3

31. Сообщение от Аноним (-), 15-Ноя-25, 05:35	+/–
> Это невозможно. Другая сторона в сетевом соединении увидит разрыв. Да ладно? Что действительно невозможно скрыть факт перезагрузки? /s До тех пор, пока ты (или что-то там ниже по сетевому стеку) не отправил другой стороне сообщения о том, что ты разрываешь соединение, другая сторона ничего не заподозрит. Единственное, что может выдать Штирлица -- это таймаут: если ты долго не будешь отправлять ACK пакеты в ответ на принятые оттуда, то сетевой стек на той стороне решит, что соединение оборвалось. Единственное что в этом мне интересно, как они перезагружают, не теряя пакетов. Полагаются на способности сетевой карты буферизировать, и быстро-быстро подменяют ядро и инициализируют новое, пока буферы не переполнились? Впрочем, несколько потерянных пакетов, наверное, не так важно, соединение потупит немного, но со временем вернётся в норму.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4

32. Сообщение от Аноним (-), 15-Ноя-25, 05:38	+/–
> Я могу придумать только продолжительный рендер без возможности прервать и срочное обновление. Перенос процесса на другую машину, потому что эта барахлит.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3

33. Сообщение от Аноним (33), 15-Ноя-25, 12:37	+/–
> Какое практическое применение есть? Чтоб можно было реализовать восстановление игр без повторного запуска, как на консолях
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #34

34. Сообщение от Аноним (3), 15-Ноя-25, 12:43	+/–
А смысл? У кого-то уже получилось?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #33

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема