аᶘ
Поведение на современных машинах такое же, как поведение чистокровного UNIX'а из 1991 года. Скорее всего это было и раньше, просто я хз, можно ли вообще сейчас как-то запустить эмулятор PDP-11 и есть ли в общем доступе первые UNIX'ы.
Size: a a a
2020 October 17
VP
Поведение переноса процессов-сирот на pid 1 с нами с 1991 года.
Интересно, как-же чувак добился реального процесса-сироту? Или всё-таки у него был зомбак? Э-эх... Боюсь мы этого не узнаем.
аᶘ
Интересно, как-же чувак добился реального процесса-сироту? Или всё-таки у него был зомбак? Э-эх... Боюсь мы этого не узнаем.
> Без родителя что - в htop он main-процессом был
Надо понять, что такое в его понимании main-процесс. Возможно как раз то, что он был под инитом без вложенностей.
Надо понять, что такое в его понимании main-процесс. Возможно как раз то, что он был под инитом без вложенностей.
VP
> Без родителя что - в htop он main-процессом был
Надо понять, что такое в его понимании main-процесс. Возможно как раз то, что он был под инитом без вложенностей.
Надо понять, что такое в его понимании main-процесс. Возможно как раз то, что он был под инитом без вложенностей.
Ну вот мне тож кажется что его-бы спас обычный
gdb -p 1 + wait(zombie_pid).S
Если процесс не убивается по -9 . Надо переписывать приложение которое неубиваемо !
Есть состояние процесса - TASK_UNITERRUPTIBLE . Процесс не будет реагировать на сигналы.
А это либо кривизна рук програмиста либо так криворукий задумал Возможно есть железобетонный аргумент почему так.
Например возможна порча файловой системы например.
Есть состояние процесса - TASK_UNITERRUPTIBLE . Процесс не будет реагировать на сигналы.
А это либо кривизна рук програмиста либо так криворукий задумал Возможно есть железобетонный аргумент почему так.
Например возможна порча файловой системы например.
OM
Если процесс не убивается по -9 . Надо переписывать приложение которое неубиваемо !
Есть состояние процесса - TASK_UNITERRUPTIBLE . Процесс не будет реагировать на сигналы.
А это либо кривизна рук програмиста либо так криворукий задумал Возможно есть железобетонный аргумент почему так.
Например возможна порча файловой системы например.
Есть состояние процесса - TASK_UNITERRUPTIBLE . Процесс не будет реагировать на сигналы.
А это либо кривизна рук програмиста либо так криворукий задумал Возможно есть железобетонный аргумент почему так.
Например возможна порча файловой системы например.
может состояние D - UNITERRUPTIBLE_SLEEP ?
OM
такое бывает при io, чаще всего дисково-сетевом. например nfs, sshfs. зависшем
OM
а прочитал с чего всё началось. да. там если дисковая система ушла в себя, пока не вернётся - процесс будет висеть.
VP
@dagaz_of_suriname Обрати внимание... А кстати, что за процесс-то был?
VP
Слушайте, а такая запись шебанга, в скрипте, корректна вообще? 😉
#!/usr/bin/rexx -e $@аᶘ
Честно говоря не уверен, что "$@" может быть проинтерпретирован ядром.
аᶘ
Хотя хз, может ядро запускает exec /usr/bin/rexx -e $@ и передаёт на stdin содержимое файла. Я вообще плаваю в понимании, как именно шебанг работает.
VP
Хотя хз, может ядро запускает exec /usr/bin/rexx -e $@ и передаёт на stdin содержимое файла. Я вообще плаваю в понимании, как именно шебанг работает.
Просто в кернельной доке по binfmt настоятельно не рекомендуется запускать обработчик имеющийся в $PATH, вот я и хочу враппер что-б без дополнительного шелла.
аᶘ
Просто в кернельной доке по binfmt настоятельно не рекомендуется запускать обработчик имеющийся в $PATH, вот я и хочу враппер что-б без дополнительного шелла.
Не очень понял, дай оригинальную цитату.
️
Слушайте, а такая запись шебанга, в скрипте, корректна вообще? 😉
#!/usr/bin/rexx -e $@аᶘ
(удоли превью, пожалуйста)
VP
аᶘ
((зачем))
Ну им вайпать охуенно, у меня это превью закрывает весь чат.