Простой -простой ответ, который является вариацией версии ОП. Иногда вам просто нужно что-то легкое для ввода или запоминания:
find. | xargs file | grep -i "broken symbolic link"
Или, если вам нужно обработать терминаторы NULL:
find. -print0 | xargs -0 file | grep -i "broken symbolic link"
Конкретной причиной того, что этот процесс не пережил вход/выход из системы во время работы под nohup, было то, что он использовал Motif. Несмотря на то, что в нашей среде для этого процесса графический интерфейс не вызывался/не реализовывался, код в конечном итоге использовал XtAppMainLoop в своем основном()(c-коде ). Возможно, библиотеки Motif что-то делают с файлом SIGNALS.
Дополнительные причины, предложенные в других ответах/комментариях:
Процесс явно перехватывает/сбрасывает SIGHUP
В процессе используется tty-устройство (s)
Если код процесса _явно перехватывает SIGHUP (, сигнал зависания )или сбрасывает его на обработчик по умолчанию (, т. е. none; т. е. выход ), это объяснило бы поведение, которое вы видите. Попросите разработчиков найти код SIGHUP
и посмотреть, что он делает.
Возможно, вы сможете лучше диагностировать это. если вы можете запустить strace
в программе, но, поскольку у вас "достаточно ограничительная среда", strace
, вероятно, недоступен. Возможно, вы сможете быстрее тестировать и создавать более действенные аналитические материалы. если вы
nohup process_a &
), ps
), kill -HUP PID
,