In <19990126230225.C12922@lucky.net> Alexandre Snarskii (snar@lucky.net) wrote:
AS> On Tue, Jan 26, 1999 at 09:48:36PM +0300, Khimenko Victor wrote:
>> >> AG> hehe. joke. what if this file is open by httpd right now ?
>> >>
>> >> Hm. And really: "what if this file is open by httpd right now?". How will
>it
>> >> affect makeindex or mv ??? I'm really puzzled -- it's perfectly legal to
>> >> remove opened file in *nix (it's not braindead Windows but real OS after
>all!).
>> >> Real removing will be posponed of course but `mv -f` should work just
>fine !
>> >> Or I'm misunderstood something ?
>>
>> AS> misunderstood, разумеется. Если у тебя бинарь, обратно на диск частично
AS> ^^^^^^
AS> i.e. страница _кода_ сброшена из vm'а. Причем не в swap, а просто
AS> сброшена, потому что ее всегда можно поднять из этого файла.
Ну это зависит от OS :-) FreeBSD AFAIK может и в swap ее загнать (так как ее
оттуда быстрее поднимать :-) Другое дело, что при запуске программы отнюдь не
все страницы кода в память загружаются и если они ни разу не были в памяти,
то и в swap'е их тоже наверняка нету...
AS> А если этот файл можно стереть (совсем стереть, так что эту страницу
AS> поднимать больше неоткуда) - то оппаньки, какой-нибудь процесс на поднятии
AS> куска _своего же_ кода получит SIGSEGV :)
Только вот как ты файл будешь _совсем_ стирать ? Каким местом ? В *nix API
нету таких функций... unlink -- он файлы не стирает, он имена файлов стирает.
А _совсем_ файл сотрет ядро. Когда сочтет нужным (скажем /sbin/init может быть
стерт только при уходе системы на перезагрузку :-) BTW в Linux'е процесс
стирания файла -- вообще процесс асинхронный (если стереть файл этак в
гигабайт-другой, то он будет еще несколько секунд стираться после того,
как unlink успешно отработает). Так что как на mv -f может повлиять
загруженность и высваповленность файла -- для меня загадка. Может просветишь ?
>> AS> высвопленный/выпейдженный, то имеешь шанс нарваться на file is busy.
>> AS> C файлами, которые подмаплены как read(и|или)write, как в данном
>> AS> случае, такого быть не может.
>>
>> Ерунда все это -- куда там что высвоплено/выпейджено есть личное дело ядра и
>> никого это не касается (конечно обычно есть способы понять -- что, куда и
>> как :-). Стереть файл (не подкаталог!) можно всегда (если прав доступа
>хватит,
>> конечно :-) Как бы иначе можно было upgrade'ить bash, rpm, init и иже с ними
>?
AS> Командой install :)
AS> rename(2)
AS> unlink(2)
AS> open(...,O_CREAT|...,...)(2)
AS> - вот такой последовательностью...
Ух ты какой шустрый... А откуда там rename возьмется, позвольте
поинтересоваться ? Конечно для устоновки в "живую" OS install я не использую,
но при upgrade RPM'а RPM'ом имеем:
-- cut --
[root@khim /root]# strace /bin/rpm -U rpm-2.5.6.KSI2-1.i586.rpm
execve("/bin/rpm", ["/bin/rpm", "-U", "rpm-2.5.6.KSI2-1.i586.rpm"], [/* 20 vars
*/]) = 0
personality(0 /* PER_??? */) = 0
[skipped]
lstat("/bin/rpm", {st_mode=0, st_size=0, ...}) = 0
unlink("/bin/rpm") = 0
open("/bin/rpm", O_WRONLY|O_CREAT, 0) = 13
write(13, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\2"..., 8192) = 8192
read(12, "\321\237g\220\330o\240\26N\271\252"..., 4096) = 4096
[skipped]
write(13, "29 980515 (egcs-1.0.3 release)\0"..., 8192) = 8192
write(13, "\0\0GCC: (GNU) egcs-2.90.29 9805"..., 8192) = 8192
write(13, "01\0\0\0\10\0\0\0\0\0\0\0\1\0\0\000"..., 6644) = 6644
close(13) = 0
getuid() = 0
chown("/bin/rpm", 0, 0) = 0
chmod("/bin/rpm", 0755) = 0
utime("/bin/rpm", [99/01/09-15:58:29, 99/01/09-15:58:29]) = 0
[skipped]
[root@khim /root]#
-- cut --
Никаких rename'ов там не было (могу личной почтой выслать весь strace -- там
80K и в list'е ему делать нечего :-). Запустился /bin/rpm, бодренько снес
/bin/rpm и положил на это место новую версию. Все. Просто и естественно.
=============================================================================
= Apache-Talk@lists.lexa.ru mailing list =
Mail "unsubscribe apache-talk" to majordomo@lists.lexa.ru if you want to quit.
= Archive avaliable at =
