Можно ли удалить kernel-debug * в производственной системе, если это мешает обновления? Шаблон KVM: / boot не хватает места
Итак, на очень хорошем хосте есть устаревшие шаблоны CentOS 6.x VPS, которые «застряли» на 100-мегабайтном / загрузочном разделе. К сожалению, поскольку он был создан ~ 4 года назад, один из наших серверов попадает в эту категорию. За исключением смены зон для получения нового пакета / шаблона с большим пространством, нет возможности увеличить размер / boot. Переключение зон было бы сложной задачей, так как нужно было бы переделывать новые IP-адреса и другие схемы, поэтому мы ищем альтернативы.
Мы используем CloudLinux на этом сервере, поэтому, возможно, ядра немного больше, чем обычно. В любом случае мы вынуждены сократить количество активных ядер до 1, что меня беспокоит, но это все, что может поместиться в / boot. Проблема в том, что не хватает места для установки новых версий ядра.
Пакеты Kernel-debug * кажутся больше стандартного ядра. Можно ли их удалить? Полезны ли отладочные ядра в производственной среде, если для загрузки [потенциально] доступна более старая версия стандартного ядра?
Это многопользовательский производственный VPS (KVM) под управлением LAMP. Мы не делаем много CLI на стороне сервера, это ' в основном ecom + webapps. У него есть kernelcare, если это может предоставить какое-то обходное решение.
С kernel-debug* вы имеете в виду как kernel-debug, так и kernel-debuginfo, так как есть разница между этими двумя пакетами
Kernel-debuginfo: Provides a executable image of the kernel with all the debug symbols
Kernel-debug: Enables some debugging code but not have same debug symbols on it
### Excerpt from RedHat Doc ###
The kernel-debug enables the following options on the kernel that are disabled on the default kernel:
CONFIG_DEBUG_SLAB
Makes kernel do limited verification on memory allocation as well as poisoning memory on free to catch use of freed memory. (performance impact mainly on kmalloc / mfree calls).
CONFIG_DEBUG_MUTEXES
Allows mutexes semantics violations to be detected and reported.
CONFIG_DEBUG_RT_MUTEXES
Allows rt mutex semantics violations and rt mutex related deadlocks (lockups) to be detected and reported automatically.
CONFIG_DEBUG_RWSEMS
Allows read-write semaphore semantics violations to be detected and reported.
CONFIG_DEBUG_LOCK_ALLOC
This feature will check whether any held lock (spinlock, rwlock, mutex or rwsem) is incorrectly freed by the kernel, via any of the memory-freeing routines (kfree(), kmem_cache_free(), free_pages(), vfree(), etc), whether a live lock is incorrectly reinitialized via spin_lock_init(),mutex_init(),etc, or whether there is any lock held during task exit.
CONFIG_PROVE_LOCKING
This feature enables the kernel to prove that all locking that occurs in the kernel runtime is mathematically correct: that under no circumstance could an arbitrary (and not yet triggered) combination of observed locking sequences (on an arbitrary number of CPUs, running an arbitrary number of tasks and interrupt contexts) cause a deadlock.
CONFIG_DEBUG_VM
Turn on extended checks in the virtual memory system (performance impact).
CONFIG_DEBUG_SPINLOCK
Built SMP to catch missing spinlock initialization and certain other kinds of spinlock errors commonly made. This is best used in conjunction with the NMI watchdog so that spinlock deadlocks are also debuggable.
CONFIG_DEBUG_SPINLOCK_SLEEP
Various routines which may sleep will become very noisy if they are called with a spinlock held.
CONFIG_LOCK_STAT
Enables tracking lock contention points ( see /usr/share/doc/kernel-doc/Documentation/lockstat.txt ).
CONFIG_XFS_DEBUG
Enable XFS debugging features, including ASSERT checks, function wrappers around macros, and extra sanity-checking functions in various code paths (make a huge and slow code).
Возвращаясь к вашему вопросу, безопасно ли их удалять?
Эти пакеты предназначены только для отладки и могут привести к снижению производительности... Так что да, они безопасно удаляются и должны устанавливаться только во время отладки.