А что произойдет, если поменять бинарник у приложения которое еще не завершило работу?

что будет с запущенным приложением?

Ничего. Бинарник прочитался, процесс запустился, больше бинарник никакого участия в работе не принимает.

Ты же не про байт-код говоришь?

Нет. Бинарник mmap-ится на память и при необходимости страницы с кодом и данными из BSS могут вытесняться.

Если нужно безопасно заменять работающий бинарник, то надо его сначала удалять, а потом писать новый файл с тем же именем.

Дело в том, что файл удаляется и создаётся заново. Но удалённый на самом деле по-прежнему 1-в-1 доступен пока программа работает.

А вот если ты его меняешь, тогда сложнее. На ЛОРе недавно было что-то в этом духе. Исполняемый бинарник обращался к самому себе (патчил на ходу?) и падал после этого.

а разве замена это не удаление и создание в одном флаконе?

Бинарник mmap-ится на память и при необходимости страницы с кодом и данными из BSS могут вытесняться.

upx негодует

Я изменил исходники и перекомпилировал - что будет с запущенным приложением?

C запущенным приложением будет все хорошо, а вот создать новый бинарник с именем запущенного ты не сможешь - линкер ругнется что не смог создать файл! (Это если ты бинарник запустил из того же каталога, где и исходники)

А компилятор случаем не удаляет старый файл и создает новый? Старый бинарник удалится, когда его все закроют.

Какая замена? Я об изменении самого файла (без удаления).

Под виндой так. Иначе такого не наблюдал.

типа подменить екзешничег ...

ааа, теперь понял. Но разве компилятор будет это делать? Ему же проще пересоздать файл

Так и делается. Я о том хитром случае поэтому отдельно во втором абзаце упомянул.

А вот если ты его меняешь, тогда сложнее. На ЛОРе недавно было что-то в этом духе. Исполняемый бинарник обращался к самому себе (патчил на ходу?) и падал после этого.

тут все понятно - просто бинарник что-то подгружает из себя, что не находится в памяти, а там файл уже другой

ОС не будет ради изменения файла создавать его копию, вот так и происходит.. Ведь в случае замены - старый файл помечается удаленным, но все кто с ним работал сохраняют к нему доступ

линкер ругнется что не смог создать файл!

нет

Может какие-то ФС ведут себя именно так? С Ext такого поведения точно нет. Как мне кажется определение поведения с открытыми файлами - это прерогатива файловой системы

Угу, некоторые так же думают, что логи удалить у работающего процесса достаточно, чтоб места свободного больше стало :))) А его больше не становится, пока дескрипторы открыты и мапится несколько гигов нулей даже в пустой лог:) А на маке не могут лог найти, но пакет с прогой распухает (это одни и те же сорцы для разных осей, написанные с одинаковыми предположениями о расположении логов).

IMHO, при компиляции целевому файлу делается unlink, а потом он создаётся заново. Поэтому новый файл действительно новый, и никак не связан с тем, что сейчас выполняется. Если попытаться начать писать в файл, который сейчас выполняется, то есть отображён в память, получим ETXTBSY.

Пятизвёздочный as is.

зависит от способа замены:

• открыть такой файл на запись тебе не дадут, будет ошибка:

  $ man 2 open
  ...
         ETXTBSY
                pathname refers to an executable image which is currently being executed and write access was requested.
  ...
  

  утилита cp выдаст в этом случае ошибку:

  cp: cannot create regular file '/path/file': Text file busy
  

• а вот rename() и соответственно mv сработают, т.к. в этом случае ядро будет держать старый файл в неизменном состоянии, пока не закроются все открытые для него дескрипторы, и легко отработает любые активности (что-то дочитать и, даже, наверно, изменить, если файл был изначально открыт на запись тоже) по этим ранее открытым дескрипторам

ок, спасибо!

У меня Qt Creator в Ubuntu позволяет запустить один экземпляр, потом поменять код и запустить еще второй из файла с тем же названием но уже измененной логикой, что немедленно отражается в GUI нового экземпляра. В принципе, так делать не желательно?

Это от фс зависит. Имхо фат и нтфс не дадут сделать rename в таком случае

позволяет запустить один экземпляр, потом поменять код и запустить еще второй из файла с тем же названием

Это же разные файлы будут, у них inode разные, хоть и одинаковые имена.

В принципе, так делать не желательно?

Все так делают. В VFS и драйверах ФС есть поддержка. Стало быть, можно. Правда, какой-то из разработчиков Chrome «жаловался», что это мешает обновлению на Linux-системах, и это одна из причин, по которым они форкаются от процесса-зиготы. Правда, я так и не понял, как блокирование имени в Windows помогает обновлениям.

Вообще сначала, как прочитал, подумал, что в Qt Creator реализовали edit-and-continue. Но, похоже, нет.

Имхо фат и нтфс не дадут сделать rename в таком случае

С vfat без проблем работает. На ntfs-3g не проверял, но тоже будет работать, скорее всего.

фат и нтфс

брысь!

А это так важно? Я предпочитаю думать, что это Undefined behaviour и соответственно не допускать такой ситуации.

Хотя вот тут в комментариях подсказывают, что это может помешать обновлениям. Но в линуксе же правильный путь - не обновлять программу из неё самой, а использовать пакетный менеджер...

Как я понял upx распаковывает в память при запуске, что не мешает системе делать mmap для не-upx бинарей.

Нет. Бинарник mmap-ится на память и при необходимости страницы с кодом и данными из BSS могут вытесняться.

Труъ. Я так попадал. Обращение к новой странице подгружало немного неожиданную для процесса страницу и он уходил во все тяжкие. Но я не удалял файл, не mv его, а копировал на целевую машину по scp и верю в то, что там он тупо перезаписывался поверх старого. Во FreeBSD почему-то такое сделать не удавалось, а в линуксе даёцца. Правда, бинарник я запускал несколько извращённым способом:

./ld-linux-x86-64.so.2 --library-path /home/user/ /home/user/mybinary --my --params

Ну вообще да. Я хочу запустить серию расчетов, и пока она там крутиться (несколько суток) поменять код и запустить еще неск серий;-)

У меня сейчас при запуске серии (много расчетов) расчеты форкаются от головного. Именно с т.з. отработки такой ситуации, потому что иначе запустился скажем циклом в баше и дыхнуть на код боишься пока не досчитает.

Но в линуксе же правильный путь - не обновлять программу из неё самой, а использовать пакетный менеджер...

Как раз из-за этого и была проблема. Chrome же изначально под Windows был выпущен, и там сам запускал себя же. Там есть уверенность, что пока хоть один процесс был запущен из конкретного exe-файла, этот файл никуда не денется. А так как обновлением Chrome заведует код самого же Chrome, был полный контроль.

При портировании на Linux вылезла проблема: пакетный менеджер может легко обновить бинарник, пока Chrome ещё запущен. И тогда открытие новой вкладки запустит уже другой бинарник. Если в процессе обновления сменился формат IPC, всё это может сгенерировать забавные глюки с малопредсказуемым эффектом.

Но в итоге они всё сделали «правильно».

не мешает системе делать mmap для не-upx бинарей.

как «система» их различает?

Никак, исполняемый сегмент мапящийся системой это распаковщик, который читает остальную часть файла сам.

Никак. В случае upx бинарь - это распаковщик. Остальное загружается в память потом. Со всякими jit происходит примерно тоже самое.

тред детектор виндузятников