Re: Как реализован in place upgrade в Дебиан? На чем основан и чем чревато?
On 2012.11.11 at 00:34:10 +0200, Oleksandr Gavenko wrote: Packages can be upgraded in place, even in running systems. Собственно понятие на юзерском уровне есть. Как бы обновление без перезаuрузки или остановки сторонних сервисов. Естественно что такие действия опасные. Например случаи: * Если разделяемая библиотека загружена в память несколькими процесами. * Если программа из одного пакета обращается к файлу из другого пакета (-bin и -data пакеты). К примеру, в Cygwin рекомендуют закрывать все Cygwin сервисы и программы. Если Cygwin работает на файловой системе NTFS. Которая не позволяет удалять файлы, открытые работающим процессом. В Unix-подобных системах, в том числе и в Linux файловая система работает по-другому. Ссылка на файл из каталога (т.н. hardlink) и ссылка на файл из открывшего его процесса фактически равноправны. На файл может существовать сколько угодно ссылок, и он физически удаляется с диска только если исчезла последняя ссылка на него. Поэтому, если удалить разделяемую библиотеку обыкновенным системным вызовом unlink(2), процессы, использующие эту библиотеку будут продолжать её видеть. А package manager или утилита install могут прекрасно записать новую библиотеку на место старой. И только при завершении последнего процесса, использюующего старую библиотеку, она физически будет удалена с диска (inode помечен как deleted). Если внимательно следить да debian-системой в процессе апгрейда основной системной библиотеки (glibc) то можно увидеть что при апгрейде иногда производится перезапуск некоторого набора сервисов. Это делается потому что glibc на самом деле не одна библиотека, а несколько (всякие там подгружаемые модули libnss). И если апгрейд таков, что процессы, подгрузившие старый libc.so не смогут при необходимости работать с новыми libnss, которые им захочется подгрузить позже, при завершении апгрейда процессы перезапускают. Кроме уже рассмотренного системного вызова unlink(2) есть еще вызов rename(2). Он отличается тем, что работает атоммарно. Поэтому если записать файл на диск под именем something.tmp а потом удалить старый something и переименовать something.tmp в something, время когда на диске не существует корректного файла c именем something (либо старого, либо нового) будет минимальным. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121112123519.ga32...@wagner.pp.ru
Re: Как реализован in place upgrade в Дебиан? На чем основан и чем чревато?
Victor Wagner vi...@wagner.pp.ru writes: […] Кроме уже рассмотренного системного вызова unlink(2) есть еще вызов rename(2). Он отличается тем, что работает атомарно. Поэтому если записать файл на диск под именем something.tmp а потом удалить старый something и переименовать something.tmp в something, время когда на диске не существует корректного файла c именем something (либо старого, либо нового) будет минимальным. Нулевым, если говорить об ФС. (Состояние /диска/ может и не быть целостным.) С поправкой на то, что явный unlink на новое имя перед вызовом rename не требуется. --cut: http://pubs.opengroup.org/onlinepubs/9699919799/functions/rename.html -- […] If the link named by the new argument exists, it shall be removed and old renamed to new. In this case, a link named new shall remain visible to other processes throughout the renaming operation and refer either to the file referred to by new or old before the operation began. --cut: http://pubs.opengroup.org/onlinepubs/9699919799/functions/rename.html -- -- FSF associate member #7257 -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/86txsvc6za@gray.siamics.net
Re: Как реализован in place upgrade в Дебиан? На чем основан и чем чревато?
On 2012-11-12, Victor Wagner wrote: Cygwin работает на файловой системе NTFS. Которая не позволяет удалять файлы, открытые работающим процессом. В Unix-подобных системах, в том числе и в Linux файловая система работает по-другому. Ссылка на файл из каталога (т.н. hardlink) и ссылка на файл из открывшего его процесса фактически равноправны. На файл может существовать сколько угодно ссылок, и он физически удаляется с диска только если исчезла последняя ссылка на него. Поэтому, если удалить разделяемую библиотеку обыкновенным системным вызовом unlink(2), процессы, использующие эту библиотеку будут продолжать её видеть. А package manager или утилита install могут прекрасно записать новую библиотеку на место старой. И только при завершении последнего процесса, использюующего старую библиотеку, она физически будет удалена с диска (inode помечен как deleted). Если внимательно следить да debian-системой в процессе апгрейда основной системной библиотеки (glibc) то можно увидеть что при апгрейде иногда производится перезапуск некоторого набора сервисов. Это делается потому что glibc на самом деле не одна библиотека, а несколько (всякие там подгружаемые модули libnss). И если апгрейд таков, что процессы, подгрузившие старый libc.so не смогут при необходимости работать с новыми libnss, которые им захочется подгрузить позже, при завершении апгрейда процессы перезапускают. Кроме уже рассмотренного системного вызова unlink(2) есть еще вызов rename(2). Он отличается тем, что работает атоммарно. Поэтому если записать файл на диск под именем something.tmp а потом удалить старый something и переименовать something.tmp в something, время когда на диске не существует корректного файла c именем something (либо старого, либо нового) будет минимальным. Как говорится - подали на ложечке. Вообще спасибо всем учасникам. Как бы дальше осмысляя появился ряд странных вопросов: * У программы есть ресурсы, например иконки, раскиданые по файлам, которые загружаюся по необходимости. Если я обновлю пакет и программа из пакета будет запущенной - то новые запросы на ресурсы вернут дескрипторы на обновленные файлы. А ведь файлы могут быть переименоваными в пакете или изменен формат данных - т.е. будет плохо? * Если доступаться к файлам пакета по требованию не безопасно с точки зрения возможности обновлять пакет in place - стоит ли писать/переписать программу в стиле - открыть все возможные файлы, а затем использовать полученые дескрипторы? -- Best regards! -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87390er2dz@gavenkoa.example.com
Re: Как реализован in place upgrade в Дебиан? На чем основан и чем чревато?
On Mon, Nov 12, 2012 at 10:29:28PM +0200, Oleksandr Gavenko wrote: * У программы есть ресурсы, например иконки, раскиданые по файлам, которые загружаюся по необходимости. Если я обновлю пакет и программа из пакета будет запущенной - то новые запросы на ресурсы вернут дескрипторы на обновленные файлы. А ведь файлы могут быть переименоваными в пакете или изменен формат данных - т.е. будет плохо? Maybe. * Если доступаться к файлам пакета по требованию не безопасно с точки зрения возможности обновлять пакет in place - стоит ли писать/переписать программу в стиле - открыть все возможные файлы, а затем использовать полученые дескрипторы? Используйте по возможности текстовые форматы, будьте толерантны к входным данным, продумайте вопросы совместимости версий. Если формат бинарный и апдейт может сломать процесс, постарайтесь зачитать файл в момент запуска. Вообще, рекомендую посмотреть главу 5 книжки Э.Рэймонда Искусство программирования для UNIX (E.Raymond, Art of UNIX Programming). -- Eugene Berdnikov -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121112210938.gg11...@sie.protva.ru
Re: После обновления ядра не отключается питание USB портов в suspend mode
11.11.2012 19:13, Alexander Danilov пишет: В моих ноутах это настраивается в bios. В стационарном включено, в носимом - выключено. На моем Thinkpad T520 тоже есть подобная опция в BIOS. Автору следует проверить у себя. Возможно новое ядро просто стало учитывать эту настройку :) -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50a1ece3.2060...@gmail.com
