Вопросы Теги

Почему делает “su-c <команда> &\” по-видимому позволяют команде работать в фоновом режиме без зависания

Если Вы хотите использовать curl, это должно работать:

curl -D - https://www.google.com/

Обратите внимание, однако, что это не точно необработанный ответ. Например, разделенное на блоки кодирование передачи не будет видимо в ответе. Используя --raw решает это, также подробный режим (-v) полезно, также и -i показывает заголовки перед органом по ответу:

curl -iv --raw https://www.google.com/

Если Вы хотите использовать пейджер как меньше на результате, также необходимо отключить индикатор выполнения (-s):

curl -ivs --raw https://www.google.com/ | less

В зависимости от того, что Вы хотите сделать, это может или не может быть проблемой.

То, что Вы действительно получаете, является всеми заголовками ответа HTTP и документом в требуемом URL.

11
22.10.2019, 15:15
1 ответ

Существует несколько способов, которыми процесс мог бы быть уничтожен из-за перестающего работать терминала.

  1. Первый путь состоит в том, что терминальный драйвер в ядре отправляет сигнал SIGHUP в процесс управления, для которого терминал является терминалом управления. В большинстве случаев процесс управления является оболочкой, которая первоначально запускается в терминале, и его терминал управления является тем, с которым подключены его stdin, stdout и stderr. Процесс становится разъединенным от терминала управления, если он звонит setsid.

  2. Второй путь состоит в том, что оболочка, когда она получает SIGHUP, снова посылает тот сигнал своим подпроцессам — более точно его фоновым заданиям. Некоторые оболочки (ksh, удар, zsh) имеют a disown встроенный, чтобы сказать оболочке не отправлять SIGHUP в конкретное задание.

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

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

12
27.01.2020, 19:58
  • 1
    я видел, что пользователь root делает chroot --userspec root:root / sh -c "exec some_forever_process" &. Задание работает как тот же пользователь без явного nohup прежде или disown позже. Таким образом для этого случая, как это - сигнал, не может быть поставлен на выходе термина? –  Toddius Zho 15.02.2018, 02:48
  • 2
    @ToddiusZho some_forever_process был предназначен для выполнения навсегда (демон) и так защищает себя от получения SIGHUP от терминального выхода (путем выполнения в его собственной группе процесса). –  Gilles 'SO- stop being evil' 15.02.2018, 19:33
  • 3
    , с которым я вставил пример 2>&1 ---------121 удар/хвост--------109294----не защищает от SIGHUP, еще который все еще работает: ''' local$ ssh root@REMOTE_HOST remote# chroot - userspec root:root / sh-c "исполнительный удар-c 'хвост-f/dev/null'" и [1] 6 376 remote# PS-p $!-o pid без заголовков, uid, хвост-ww 6376 0 команды-f/dev/null remote# local$ выхода ssh root@REMOTE_HOST remote# PS-p 6376-o pid без заголовков, uid, хвост-ww 6376 0 команды-f/dev/null' '' –  Toddius Zho 16.02.2018, 21:02

Теги

Похожие вопросы