Что делает программа, когда ей посылается сигнал SIGKILL?
Объединив этот ответ с наиболее известными вариантами для shred, используя эту ссылку stack overflow 'Deleting Files Permanently and Securely on CentOS':
find -depth -type f -exec shred -v -n 1 -z -u {} \;
Edit: Помните, что лучший ответ для уничтожения одного файла заставляет синхронизацию, которая записывает изменения на носитель перед удалением файла, потому что некоторые или все журналируемые файловые системы имеют буфер.
Если возможно, команда find должна вызывать сценарий оболочки на файле, который выполняет:
shred -v -n 1 /path/to/your/file #overwriting with random data
sync #forcing a sync of the buffers to the disk
shred -v -n 0 -z -u /path/to/your/file #overwriting with zeroes and remove the file
на каждом файле.
На самом деле программа никогда не получает сигнал SIGKILL, так как сигнал SIGKILL полностью обрабатывается операционной системой/ядром.
Когда посылается сигнал SIGKILL для определенного процесса, планировщик ядра немедленно перестает выделять этому процессу процессорное время для запуска пользовательского -кода пробела. Если в процессе есть какие-либо потоки, выполняющие код пользовательского пространства -на других процессорах/ядрах в то время, когда планировщик принимает это решение, эти потоки также будут остановлены. (В одноядерных -системах это было намного проще, :если единственное ядро ЦП в системе запускало планировщик, оно по определению не запускало процесс одновременно!)
Если процесс/поток выполняет код ядра (, например. системный вызов или операция ввода-вывода, связанная с файлом отображения памяти -)во время SIGKILL, становится немного сложнее :только некоторые системные вызовы прерываемы, поэтому ядро внутренне помечает процесс как находящийся в особом «умирающем» состоянии, пока не будут разрешены системные вызовы или операции ввода-вывода. Процессорное время для их решения будет запланировано как обычно. Прерываемые системные вызовы или операции ввода-вывода проверяют, умирает ли вызвавший их процесс в любых подходящих точках остановки, и в этом случае завершаются досрочно. Непрерывные операции завершатся и будут проверены на «умирающее» состояние непосредственно перед возвратом к пользовательскому коду пробела -.
Как только любые в -процедурах ядра процесса разрешены,состояние процесса изменяется с «умирающий» на «мертвый», и ядро начинает его очищать, подобно тому, как программа завершается нормально. Как только очистка -завершена, код результата -больше, чем -128, будет назначен (, чтобы указать, что процесс был остановлен сигналом; см. этот ответ для подробностей ), и процесс перейдет в состояние «зомби». Родитель убитого процесса будет уведомлен сигналом SIGCHLD.
В результате у самого процесса никогда не будет возможности обработать информацию о том, что он получил сигнал SIGKILL.
Когда процесс находится в состоянии «зомби», это означает, что процесс уже мертв, но его родительский процесс еще не подтвердил это, прочитав код завершения мертвого процесса с помощью системного вызова wait(2). По сути, единственный ресурс, который больше потребляет процесс-зомби, — это слот в таблице процессов, в котором хранится его PID, код выхода и некоторые другие «важные статистические данные» процесса на момент его смерти.
Если родительский процесс умирает раньше, чем его дочерние процессы, осиротевшие дочерние процессы автоматически принимаются PID #1, который имеет особую обязанность продолжать вызывать wait(2), чтобы любые осиротевшие процессы не оставались зомби.
Если для очистки зомби-процесса требуется несколько минут, это означает, что родительский процесс-зомби испытывает трудности или не выполняет свою работу должным образом.
Есть язык -в -щековом описании того, что делать в случае проблем с зомби в Unix -типа операционных систем :"Вы ничего не можете сделать для самих зомби, так как они уже вместо этого убейте злого повелителя зомби! " (т.е.родительский процесс проблемных зомби)