Re: Как реализован "in place upgrade" в Дебиан? На чем основан и чем чревато?
On Tue, Nov 13, 2012 at 10:42:51PM +0200, Oleksandr Gavenko wrote: > On 2012-11-12, Eugene Berdnikov wrote: > > Вообще, рекомендую посмотреть главу 5 книжки Э.Рэймонда "Искусство > > программирования для UNIX" (E.Raymond, "Art of UNIX Programming"). > > Можно перечитать. Последний подраздел главы "отсылает" нас к SOAP, XML-RPC и > Jabber. Хотя, например: > > http://about.psyc.eu/Jabber#Technical_Issues_in_Jabber > > * Major disadvantage: Performance inefficiency > * Major disadvantage: Binary Data Transfer > * Major problem with XMPP: Missing framing Всё это, если присмотреться, проблемы растущие из выбора XML в качестве базового формата. Сто раз подумайте, нужен ли подобный гроб с музыкой для вашей задачи... -- 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/20121114064826.gm16...@protva.ru
Re: Как реализован "in place upgrade" в Дебиан? На чем основан и чем чревато?
On 2012-11-12, Eugene Berdnikov wrote: >> * Если доступаться к файлам пакета по требованию не безопасно с точки зрения >>возможности обновлять пакет "in place" - стоит ли писать/переписать >>программу в стиле - открыть все возможные файлы, а затем использовать >>полученые дескрипторы? > > Используйте по возможности текстовые форматы, будьте толерантны к входным > данным, продумайте вопросы совместимости версий. Если формат бинарный и > апдейт может сломать процесс, постарайтесь зачитать файл в момент запуска. > Вообще, рекомендую посмотреть главу 5 книжки Э.Рэймонда "Искусство > программирования для UNIX" (E.Raymond, "Art of UNIX Programming"). Можно перечитать. Последний подраздел главы "отсылает" нас к SOAP, XML-RPC и Jabber. Хотя, например: http://about.psyc.eu/Jabber#Technical_Issues_in_Jabber * Major disadvantage: Performance inefficiency * Major disadvantage: Binary Data Transfer * Major problem with XMPP: Missing framing В духе книги, нужно еще просмотреть сто тысяч примеров... -- 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/878va5kzec@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: Как реализован "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" в Дебиан? На чем основан и чем чревато?
> Victor Wagner 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.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" в Дебиан? На чем основан и чем чревато?
а, понял. таки да, при изменении выдает ошибку. через удаление и пересоздание - пожалуйста. 2012-316 21:45 Andrey Rahmatullin wrote: > > все удалилось без вопросов, процесс висит. > > аналогично проделал с yes - вывод продолжается... > Что вас удивляет? man 2 unlink > -- 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/2012223312.6e2c0...@ulf.tvoe.tv
Re: Как реализован "in place upgrade" в Дебиан? На чем основан и чем чревато?
Andrey Rahmatullin writes: >> поэтому при попытке замены выдаётся Text File Busy. > Не замены, а открытия на запись. > А то, что в библиотеки писать не запрещено - по-моему, просто странные > детали реализации. Стало быть, при замене пакета сначала удаляются файлы старого пакеты, а затем на их место распаковываются новые? -- ** * jabber: free...@jabber.mipt.ru * * Registered linux user #546240* ** -- 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/87625cm96z@ws00.freehck.ru
Re: Как реализован "in place upgrade" в Дебиан? На чем основан и чем чревато?
On Sun, Nov 11, 2012 at 07:24:44PM +0400, dimas wrote: > > Нет, исполняющиеся бинарники отмаплены на их файлы, > > поэтому при попытке замены выдаётся Text File Busy. > > хм, а если так: > > cp /bin/sleep /tmp > cd /tmp/ > start-stop-daemon -Sbvx /tmp/sleep -mp /tmp/sleep.pid -- 20m > rm ./sleep > ps `cat sleep.pid` > > все удалилось без вопросов, процесс висит. > аналогично проделал с yes - вывод продолжается... Что вас удивляет? man 2 unlink -- WBR, wRAR signature.asc Description: Digital signature
Re: Как реализован "in place upgrade" в Дебиан? На чем основан и чем чревато?
On Sun, Nov 11, 2012 at 09:15:10PM +0600, Dmitry Fedorov wrote: > >> а в остальных - запущенный бинарник уже в памяти давно висит, ему же все > >> равно, что там на диске с ним, разве нет? > > Обычно да, но в пакетах не только бинарники. > Нет, исполняющиеся бинарники отмаплены на их файлы, Какая разница. > поэтому при попытке замены выдаётся Text File Busy. Не замены, а открытия на запись. А то, что в библиотеки писать не запрещено - по-моему, просто странные детали реализации. -- WBR, wRAR signature.asc Description: Digital signature
Re: Как реализован "in place upgrade" в Дебиан? На чем основан и чем чревато?
> Нет, исполняющиеся бинарники отмаплены на их файлы, > поэтому при попытке замены выдаётся Text File Busy. хм, а если так: cp /bin/sleep /tmp cd /tmp/ start-stop-daemon -Sbvx /tmp/sleep -mp /tmp/sleep.pid -- 20m rm ./sleep ps `cat sleep.pid` все удалилось без вопросов, процесс висит. аналогично проделал с yes - вывод продолжается... -- 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/2012192444.30cc7...@ulf.tvoe.tv
Re: Как реализован "in place upgrade" в Дебиан? На чем основан и чем чревато?
11 ноября 2012 г., 21:53 пользователь Andrey Rahmatullin написал: > On Sun, Nov 11, 2012 at 03:10:01PM +0400, dimas wrote: > >> а в остальных - запущенный бинарник уже в памяти давно висит, ему же все >> равно, что там на диске с ним, разве нет? > Обычно да, но в пакетах не только бинарники. Нет, исполняющиеся бинарники отмаплены на их файлы, поэтому при попытке замены выдаётся Text File Busy.
Re: Как реализован "in place upgrade" в Дебиан? На чем основан и чем чревато?
On Sun, Nov 11, 2012 at 03:10:01PM +0400, dimas wrote: > демоны-то как раз перезапускаются, когда надо. ejabberd, samba, ssh, например > - при обновлении очень даже рестартятся. Только при обновлении себя, но не библиотек. См. тж. checkrestart(1) из пакета debian-goodies. > а в остальных - запущенный бинарник уже в памяти давно висит, ему же все > равно, что там на диске с ним, разве нет? Обычно да, но в пакетах не только бинарники. > кстати, либы тоже в память грузятся, подскажите кто-нибудь? Либы ммапятся, как и исполняемые файлы. -- WBR, wRAR signature.asc Description: Digital signature
Re: Как реализован "in place upgrade" в Дебиан? На чем основан и чем чревато?
демоны-то как раз перезапускаются, когда надо. ejabberd, samba, ssh, например - при обновлении очень даже рестартятся. из "опасного" - gdm, например, который, если запущен в момент обновы, спрашивает, перезапустить ли сейчас (грохнув иксы и все брахало в них), или пущай дальше работает, а в следующий раз новая версия запустится (могу ошибаться в деталях, но суть такая). еще вот недавно была эпопея со screen - в тестинге, по крайней мере. в последний раз вроде более-менее мирно прошло (ну, сказали там, что какая-то парочка функций не будет работать до перезапуска, и ладно), а вот до этого писали про ваще поломанную совместимость, и при обнове старый файл копировался в /tmp/screen-x.y.z , и нужно было его запущать, чтобы поработать в старых сеансах. в общем, потенциально геморройные случаи продумываются заранее и растолковываются в чейнджлогах (apt-listchanges в помощь). а в остальных - запущенный бинарник уже в памяти давно висит, ему же все равно, что там на диске с ним, разве нет? просто при следующем запуске стартует уже новый файл. кстати, либы тоже в память грузятся, подскажите кто-нибудь? -- 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/2012151001.01bd9...@ulf.tvoe.tv
Re: Как реализован "in place upgrade" в Дебиан? На чем основан и чем чревато?
On Sun, Nov 11, 2012 at 12:34:10AM +0200, Oleksandr Gavenko wrote: > * Если разделяемая библиотека загружена в память несколькими процесами. То? > * Если программа из одного пакета обращается к файлу из другого пакета (-bin > и >-data пакеты). "А вы так не делайте" > Что позволяет (какие системные вызовы, с какими параметрами) производить "in > place upgrade" в Debian? unlink(2) rename(2) -- WBR, wRAR signature.asc Description: Digital signature
Как реализован "in place upgrade" в Дебиан? На чем основан и чем чревато?
Читаю debian-faq: 9.1. How can I keep my Debian system current? - Note that `dpkg' will install upgrade files in place, even on a running system. 9.2. Must I go into single user mode in order to upgrade a package? --- Packages can be upgraded in place, even in running systems. Собственно понятие на "юзерском" уровне есть. Как бы обновление без перезаuрузки или остановки сторонних сервисов. Естественно что такие действия "опасные". Например случаи: * Если разделяемая библиотека загружена в память несколькими процесами. * Если программа из одного пакета обращается к файлу из другого пакета (-bin и -data пакеты). К примеру, в Cygwin рекомендуют закрывать все Cygwin сервисы и программы. Если файл открыт как исполнимы бинарный образ - то его не перезатереть из-за ограничений Windows и setup.exe собирает список таких файлов, что бы обновить их при перезагрузке, по хуку runonce в реестре. RedHot Linux не имеет официального "in place upgrade" (по старым ответам из веб-поиска). Что позволяет (какие системные вызовы, с какими параметрами) производить "in place upgrade" в Debian? Какие возможные проблемы это может вызвать в стабильности работы дистрибутива? -- 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/87bof53x5p@gavenkoa.example.com