a) Проверьте, регистрируются ли сообщения ядра в файл rsyslog демоном
vi /etc/rsyslog.conf
И добавьте следующее
kern.* /var/log/kernel.log
Перезапустите rsyslog
сервис.
/etc/initd.d/rsyslog restart
b) Обратите внимание на загруженные модули
`lsmod >/your/home/dir`
c) Поскольку паника не восстанавливаема, ожидайте ее для случая
d) После того как паника произошла, загрузите систему с помощью живого или чрезвычайного CD
e) Смонтируйтесь файловые системы (обычно / будет достаточен, не являются ли / var и / домой отдельными файловыми системами) затронутой системы (pvs
, vgs
, lvs
команды должны быть выполнены при использовании LVM в затронутой системе для перевода в рабочее состояние LV), mount -t ext4 /dev/sdXN /mnt
f) Перейдите в /mnt/var/log/
каталог и проверка kernel.log
файл. Это должно дать Вам достаточно информации, чтобы выяснить, происходит ли паника для конкретного модуля или чего-то еще.
Использовать eval
:
filemsgCICS=foo
word1=CICS
eval "echo \"\$filemsg$word1\"" # => foo
eval "filemsg$word1=bar"
echo "$filemsgCICS" # => bar
но думайте дважды, нужен ли Вам действительно он этот путь.
Иначе в ksh93
должен использовать namerefs:
word1=CICS
nameref v=filemsg$word1
v="xxx"
echo "$filemsgCICS" # => xxx
Для еще более противных взломов как этот взгляд здесь.
export
делает это намного безопаснее, чем eval
, поскольку нет опасности того, что он выполнит код оболочки после маркера оболочки. Но он делает экспорт
переменных, чтобы вы могли принимать их как хотите.
export "filemsg$word1= "
Попробуйте это
let filemsg"$word1"=" "
Возможно, это не лучшее решение, но в прошлом оно мне помогало.
Это не POSIX , но в bash
всегда есть printf -v
, который печатает не в стандартный вывод, а в любое имя переменной, следующее за ним-v
:
x=foo; printf -v $x bar; echo $foo
Выход:
bar
Попробуйте это:
filemsgCICS=foo
word1=CICS
ref_filemsg=filemsg$word1
echo ${!ref_filemsg} => foo
Попробуйте это:
word1=CICS
var_name=filemsg$word1
eval ${var_name}="var_value"
Для проверки:
echo $filemsgCICS ==> var_value