Если вы получаете AVC selinux, вы можете настроить локальную политику для разрешения этого конкретного действия, используя инструмент audit2allow
:
# audit2allow -M local -a
Это создаст локальную политику (. pp
), которая позволит все, что привело к отказу selinux в ваших журналах аудита. Затем вы можете активировать этот модуль, запустив:
# semodule -i local.pp
Вы можете увидеть источник в файле local.te
.
Результатом работы AVC в вашем вопросе будет:
module local 1.0;
require {
type fprintd_t;
type initrc_t;
class dbus send_msg;
}
#============= fprintd_t ==============
allow fprintd_t initrc_t:dbus send_msg;
Программы (и сценарии )могут игнорировать большинство сигналов, за исключением некоторых, подобных KILL
. Сигнал HUP
может быть перехвачен и проигнорирован, если того желает программа.
Это из src/main.c
из wget
источников (версия 1.19.2):
/* Hangup signal handler. When wget receives SIGHUP or SIGUSR1, it
will proceed operation as usual, trying to write into a log file.
If that is impossible, the output will be turned off. */
Чуть ниже установлен обработчик сигналов:
/* Setup the signal handler to redirect output when hangup is
received. */
if (signal(SIGHUP, SIG_IGN) != SIG_IGN)
signal(SIGHUP, redirect_output_signal);
Похоже, что wget
не игнорирует сигнал HUP
, а продолжает обработку с перенаправлением вывода в файл журнала.
Запрошено в комментариях. :Значение ?
в столбце TTY
вывода ps
в вопросе заключается в том, что процесс wget
больше не связан с терминалом/TTY.TTY исчез, когда соединение SSH прервалось.
Простой:wget
не прерывается на SIGHUP
. Однако это происходит на SIGTERM
и SIGINT
.
На странице man
ничего нет, но если вы отправили SIGHUP
в процесс wget
, вы получите это в терминале:
# in a different terminal while wget is running (with PID 12345)
kill -HUP 12345
# in the wget terminal
SIGHUP received.
Redirecting output to 'wget-log'.