Удаление неиспользованных init сценариев

Вы хотите stty команда: посмотрите, как ^D отображается с stty -a. Можно изменить это на что-то еще с stty eof char: Удалите "eof", устанавливающий с stty eof undef


Непротестированный: Вы хотите читать о trap команда в ksh странице справочника. Это могло бы быть достаточно, чтобы Вы настроили обработчик для EXIT сигнал.

# warning: completely untested
exit_handler() { echo "exit"; exit; }
trap exit_handler EXIT

5
25.04.2014, 00:47
5 ответов
[112288]Вы действительно ничего не оптимизируете, удалив эти скрипты. Скрипты [112593]*-bootclean.sh[112594] очищают файлы, которые должны или не должны перезагружаться: файлы в [112595]/var/run[112596], [112597]/var/lock[112598], [112599]/tmp[112600] и др. В Debian с SysVinit есть три таких сценария:
  • checkroot-bootclean.sh[112652] запускается сразу после монтирования корневой файловой системы (что может удалить поддельные файлы, созданные в каталогах, которые вскоре станут точками монтирования, такие как [112653]/run[112654] и потенциально [112655]/tmp[112656])
  • mountall-bootclean.sh[112658] запускается после монтирования локальных файловых систем (в том числе и e. g. локальная отдельная [112659]/tmp[112660] или [112661]/var[112662] - или tmpfs файловая система, но на них нечего чистить)

    mountnfs-bootclean. sh[112664] выполняется после монтирования удалённых файловых систем (включая, например, [112665]/var[112666] через NFS).

    Отключение [112607]mountnfs.sh[112608] и [112609]mountnfs-bootclean.sh[112610] не повредит вашей системе. Однако, чтобы определить это, необходимо внимательно изучить их. Более того, это применимо только в предположении, что вы никогда не поместите файловую систему NFS в fstab. Если вы знаете, что это правда, то я бы очень хотел, чтобы вы впитали в меня свои способности гадания. Если вы просто верите, что это правда, то вы должны принять во внимание риск того, что ваше убеждение в какой-то момент окажется необоснованным.

    Каждое умолчание, которое вы изменяете в дистрибутиве, делает вашу систему другой, поэтому часть документации больше не применяется, тесты, которые провели другие, могут больше не применяться, поддержка, которую вы можете получить, может быть признана недействительной, и т.д. Любое изменение в настройках по умолчанию по своей природе является дополнительным осложнением, и поэтому должно выполняться только в том случае, если из него можно извлечь реальную пользу. Ваше утверждение, что удаление этих сценариев упростит процесс загрузки, ложно, так как вы не учли это.[112297].

    6
    27.01.2020, 20:31
    [112265]Я бы никогда не удалил init.d scripting.....Что я бы сделал, так это деинсталлировал пакет, который вам больше не нужен. Файл init.d должен быть удален в результате удаления пакета.
  • Удаление пакета удовлетворяет вашей потребности в упрощении и, возможно, удалении некоторого необходимого дискового пространства. [112268]
  • 7
    27.01.2020, 20:31
    [112255]Я не вижу никакого прироста производительности при удалении этих инитскриптов. Функция [112565]do_wait_async_mount()[112566] разбирает fstab и если не находит файловые системы nfs, то просто ничего не делает. Выполнение скрипта занимает менее половины секунды на моей системе, которая также не имеет никакого монтирования NFS:
    Вы можете удалить их, но прирост производительности не стоит усилий.[112258].
    4
    27.01.2020, 20:31
    [112286] Резервное копирование просто - и [112587] все равно уже должно быть сделано [112588]. Восстановление - это простое дело. Ваш риск близок к нулю, но то, что вы можете получить - даже в случае неудачи - это опытное знание. Я говорю - вперед. Я говорю удалять каждый скрипт до тех пор, пока машина не откажется загружаться. Я пойду на один шаг дальше и скажу, что не беру на себя никакой ответственности за результат, но, серьезно, худшее, что может случиться - это то, что вы [112589] чему-то научитесь.
  • 2
    27.01.2020, 20:31
    [112902]Для решения проблемы простоты:
  • Удаление сценариев, которые были созданы минимальным дистрибутивом или установкой пакетов, обычно плохая идея - вы не знаете, какие процессы могут на них полагаться.
  • Удаление пакета [113642], в котором были созданы файлы, может быть вполне разумным. Чтобы узнать:

    yum предоставляет /etc/rcS.d/S12mountnfs.sh /etc/rcS.d/S13mountnfs-bootclean.sh

  • Если вы не можете достичь желаемой простоты с Debian, или хотите узнать больше о том, как работает процесс загрузки, вы можете попробовать пустой дистрибутив типа [113589]Arch[113590].

    0
    27.01.2020, 20:31

    Теги

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